PDA

View Full Version : F16 - GRUB2 EFI non-Mac



Don3
6th February 2012, 11:02 PM
Apologies if this has been answered elsewhere, but what's the current status on GRUB2 for non-Mac x86 32 and 64-bit computers with [U]EFI boot, using latest Fedora 16 repos (ie, from network install using 64-bit minimal boot CD)? Should I be spending time trying to get this to work, or is GRUB1 (Legacy) still the way to go at this time? This is my first attempt at EFI booting, and various posts here and other Google hits seem a bit contradictory, or perhaps just out of date -- some of what I've read indicates that improvements have made during the last few months, during the F16 release and maybe later..?

A few details:

mainboard: Intel DP35DP, BIOS ver 0572 (2009-07-16) set for EFI and AHCI
CPU: Core2 Duo E4600
disc: Seagate ST31000528AS (1 TB SATA2)


Thanks
Don

fpmurphy
7th February 2012, 03:57 PM
Short answer - it works. Longer answer - you may or may not be able to get it working; it all depends on your level of expertise. The EFI implementations on many of the older Intel motherboards is interestingly different. The workaround is to make the partition bootable.

chrismurphy
7th February 2012, 07:18 PM
AFAIK, Fedora Project / RH, are still using their GRUB Legacy EFI derivative including in Rawhide and F17. Certainly that is the case for F16.

So it's a question of whether GRUB Legacy EFI or GRUB2 EFI works better for your hardware. If equal, then it probably makes more sense to take the plunge to GRUB2 EFI since it's consistent with upstream and other distros. But for me it was a painful learning curve. There are in effect four GRUBs...and they each have their own peculiarities.

Don3
7th February 2012, 09:17 PM
Thanks (to both murphys)... Right now my situation is that neither GRUB Legacy nor GRUB2 seem to be doing the trick for me with EFI. I figured I would have to dive into one of them, and as you say, I thought it might make more sense to spend (er, invest) the time on GRUB2 -- unless it's known not to work.

Initially I was trying to use a custom partition layout with multiple discs, but in order to make it easier to explain, and to reduce variables, I've unplugged all but the one HDD, wiped the entire thing with 0x00s (using dd), and used the installer's default partitioning. The installation goes fine until the end, when I get a dialog which says:


Warning
There was an error installing the bootloader.
The system may not be bootable.

(FWIW, I haven't seen this warning when using custom partitioning.)
The only interesting thing I see on any of the virtual console screens is this:


ERR kernel:[ 8420.344447] efivars: DataSize & Atrributes must be valid!

And indeed the system is not bootable -- the BIOS displays:


No bootable device -- insert boot disk and press any key

Using gdisk on SystemRescueCD, I see ESP and boot partitions have been created (and apparently the boot partition is the wrong type):


% gdisk -l /dev/sda
. . .
Found valid GPT with protective MBR; using GPT.
. . .
Number Start (sector) End (sector) Size Code Name
1 2048 75098111 35.8 GiB EF00 EFI System Partition
2 75098112 76122111 500.0 MiB 0700
3 76122112 1953523711 895.2 GiB 8E00


I mounted the root, boot, and EFI system partitions (chroot'd in the rescue system) and I see the ESP contains just one file:


# find /boot/efi ! -type d
/boot/efi/EFI/redhat/grub.efi

@fpmurphy: When you say "make the partition bootable", I assume you mean the ESP... From what I can see, gdisk doesn't use that terminology but parted does:


# parted -l /dev/sda
. . .
Partition Table: gpt

Number Start End Size File system Name Flags
1 1049kB 38.5GB 38.4GB fat32 EFI System Partition boot
2 38.5GB 39.0GB 524MB ext4
3 39.0GB 1000GB 961GB lvm
. . .

If you have any ideas from this, please let me know. Otherwise I'll have a closer look at GRUB2 docs and see if I can install it manually from here. I made a half-hearted attempt earlier (with the custom partitioning) which didn't work, but now that I know it "should", I might try a little harder.

chrismurphy
7th February 2012, 09:33 PM
A very sketchy area of (U)EFI implementations is how to present boot options to the user. My understanding of the UEFI spec is that there is a default bootloader that must be honored by default if present, and that's
EFI(systempartition)//EFI/BOOT/BOOTX64.efi

If not present, then it appears entirely up to your computer's UEFI implementation to decide whether to present other bootloaders or not at all, including total boot failure. This seems moronic, but it appears to be really common.

Fedora installs the grub.efi bootloader in:
EFI//EFI/redhat/grub.efi

(pretty sure that's right...close anyway, and might be different between legacy and grub2).

So in every case (on Apple hardware), I've had to create a BOOT folder, and copy/rename grub.efi to BOOTX64.efi.

Now, maybe your UEFI implementation has a key command at boot time to bring up a menu from which it will then be compelled to look in EFI//EFI/* and present options to you. Apple hardware does not have such a GUI feature, it does have a "bless" command that can be used to place a pointer in NVRAM to bootloaders in pretty much any location.

---------- Post added at 01:33 PM ---------- Previous post was at 01:25 PM ----------

So what you need to do first is see if your UEFI implementation has any user interactivity options to choose a bootloader, and see if it finds grub when you do that. If you don't have an interactivity with your UEFI implementation then you probably will need to do something like this:

start off a liveCD
mkdir /mnt/efi
mount -t vfat /dev/sda1 /mnt/efi
cd /mnt/efi/EFI/
ls -l

Then you'll see what folders you have and figure out where the grub bootloader is, create a /mnt/efi/EFI/BOOT folder and inside of that put grub.efi renamed as BOOTX64.efi.

Now another problem I've had that's confusing and I'm not totally sure I understand, is I think that BOOTX64.efi has the location of grub.cfg baked into it. So I've had problems where doing the above causes GRUB2 to be found but since it can't find /boot/grub2 where all of the GRUB2 modules and grub.cfg are located, it comes up in rescue mode.

If that happens to you post back. There are a couple of ways to skin that cat. One is to use some rescue commands to get GRUB back into normal mode, and load grub.cfg - then once you're live booted off your actual install, to have grub2-efi-install create a new grub.efi, which then should be used to replace the one that isn't working.

It's fakaked. It should not be this difficult. It pisses me off beyond belief that we get a new BIOS paradigm and it's this f'n user hostile, apparently by design.

Don3
8th February 2012, 06:51 AM
Thanks for your suggestions!

The only mention of EFI I see in the BIOS system setup screens is one item on the "Boot" page called "UEFI boot", and that's either enabled or disabled[1]. I haven't seen any other options that seem related to a choice of things to boot. 'Course I could always be missing something obvious.

Your suggestion of copying (EFI-partition)/EFI/redhat/grub.efi to the default (EFI-partition)/EFI/BOOT/BOOTX64.efi seemed promising (and consistent with other things I've read), but unfortunately it didn't change the behavior -- it still stops with "No bootable device". It doesn't seem to be the issue you mentioned with the canned-in config file path -- I don't think it's getting that far.

I also found some interesting reading (http://www.rodsbooks.com/efi-bootloaders/index.html), by Rod Smith, the author of gdisk. In his opinion (as of last September), ELILO might be the easiest to get working. However, if I'm interpreting the single error message from my BIOS correctly, the BL is not even being found yet, so I'm thinking ELILO vs GRUB(1) vs GRUB2 might be kind of moot at this point.

Back on the topic of choosing bootloaders, I got kind of excited when I read about using efibootmgr to manipulate boot manager settings, but unfortunately when I run it [from the rescue CD env, which I'm using to write this; I will try again from the Fedora install CD when I'm done here], I get this


# efibootmgr
Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.


"modprobe efivars" runs without complaint but I don't see it in lsmod's output after that, and it doesn't help efibootmgr at all. (I think I remember seeing complaints from grub2-efi-install about efibootmgr failing, back when I tried that, and that was with the Fedora install env.)

I also tried looking through release notes and other Intel docs for this board for clues about what EFI release my BIOS was intended to be compliant with. No luck there either. I was thinking that perhaps 2009 BIOS vintage might be too early to expect functional/compliant EFI booting(?).

I agree -- I wouldn't have thought this would be so difficult...

----------------
[1] - In my case, UEFI boot is essentially permanently enabled now. This machine ran Fedora 8 for over 4 years with it disabled, but for the F16 installation I decided to try enabling it, which one could say got me into this mess. Since then changes to a number of BIOS settings, including this one, do not stick after rebooting. The battery voltage seems fine (3.2 V), and removing it reset the time-of-day clock but didn't help otherwise.

chrismurphy
8th February 2012, 07:29 AM
I assume you've looked at all of this:
http://www.intel.com/support/motherboards/desktop/sb/CS-028780.htm#splash

You might dig around for shellx64.efi and drop that into the root directory of the EFI System Partition and see if you get an EFI shell. There are links to various shells and how to use them here:
https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Important_UE FI_Shell_Commands

I'd bet that it's UEFI 2.x compliant. I think you're just going to have to work through some things to find out what it wants and maybe you can get some Intel email support or something. It should work.

---------- Post added at 11:29 PM ---------- Previous post was at 11:28 PM ----------

And if it doesn't work, you can punt and disable UEFI support and just make it a BIOS install. It does somewhat limit the hardware's capability, but I doubt it makes it noticeably slower or anything (maybe some limited power management support, slower initial boot time, limits on disk sizes, etc).

Don3
8th February 2012, 07:42 AM
Ahh right, thanks, I'd forgotten about that jumper... I'll try that tomorrow if I get some time.

I had seen the EFI shell mentioned before, but hadn't figured out whether it was something built in to some EFI implementations or a separate executable. Thanks for that link too.

In the FWIW dep't...
Seems I was wrong, or something changed: I just tried running efibootmgr under the F16 minimal install CD, and it ran fine. So I tried


efibootmgr -c -l \\EFI\\redhat\\grub.efi

which added a "Boot0000*" entry [this is from memory, so may not be quite right] to the output that wasn't there before. Again I got excited that I might have stumbled into goodness, but the result is still the same: "No bootable device".

I'll update if I get anywhere with this. It may be a couple days before I can come back to it.

chrismurphy
8th February 2012, 08:03 AM
I'm pretty sure you don't need to interact with efibootmgr directly. I think grub2-efi-install does that for you as part of its various scripts.

---------- Post added 8th February 2012 at 12:03 AM ---------- Previous post was 7th February 2012 at 11:58 PM ----------

The gotcha is that it's less than obvious how to get it to install on a disk other than the boot disk. Whenever I tried to use the flag that points it to another disk, I get errors about /sys and /proc.

So what I did was boot from F16 DVD EFI, and by the way by virtue of booting off the DVD you must've gotten an EFI boot to work! Anyway, from the F16 boot menu find troubleshooting then choose the rescue option in the next menu. Then wait. Then go through the menus, you don't need to activate network, do let it look for installations and pretty much choose the default options each time I think. At the end get to a shell where it's already mounted everythign for you at /mnt/sysimage. Then you just do a chroot /mnt/sysimage.
Then if you do grub2-efi-install --no-floppy --recheck /dev/sda

It should work. You might still need to go find grub.efi on the EFI partition and rename and relocate it (again).

Don3
8th February 2012, 04:58 PM
...by virtue of booting off the DVD you must've gotten an EFI boot to work

Hmm, interesting. Actually I've been using the net-install CD (not a DVD), but still interesting. That's been working all along -- er, well, it's a bit flaky (on some boots it doesn't realize the CD is in the drive, and if I'm not mistaken it sometimes gives a console text menu instead of the "prettier" one), but basically it's been working all along. I had assumed it was just because the optical drive is first in the boot order on the Boot page of the BIOS setup screen. Hadn't occurred to me EFI would be involved there too -- I guess I just took it for granted that it was still working from before, when EFI boot was disabled.

OK, I will try downloading the install DVD and give that a shot. And I still need to try the previous things -- the BIOS config jumper and trying to boot into the EFI shell. Unfortunately I may not have much time available to work on this in the next couple days, we'll see...

Thanks!

Don3
20th February 2012, 07:23 AM
Well, turned out I was busy for a lot longer than I expected. I'll try to summarize the results from the things I've tried in the last week or so, going back over your suggestions. I've probably forgotten a few things by now too.


Following Intel's documentation, I moved the BIOS config jumper to the "configure"position, hoping there might be some extended EFI boot parameters that could be viewed and changed. It did add some some extra config parameters, but nothing to do with EFI.

I copied a BIOS recovery file to a USB flash drive (I assume they mean with a FAT file system on the drive), removing the BIOS config jumper and booting. No sign of activity - LED on flash drive stays off, no video output, nothing. Waited well beyond the 2-5 minutes quoted, and tried several times.

Replaced BIOS config jumper in "normal" position. Back to previous behaviour -- EFI boot setting still seems to be permanantly enabled, and it still finds "No bootable device".

Tried pressing F10 at boot time, which presents a menu of boot devices (I hadn't realized that before), outside the BIOS setup screens. Tried each one in turn, but none (except possibly the CD/DVD drive) do anything. In fact, when I tried the hard drive entry, it not only didn't boot, but it disappeared from the list.

Downloaded the full F16 install DVD. As with the minimal boot CD, the DVD's boot menu has only one choice, "Fedora 16", so I took that and ran through an "upgrade" installation. It seems to have recognized that there was nothing to do, but offered to install the bootloader. All looked well until the end when a dialog announced that the bootloader installation had failed and the machine might be unbootable. (I don't have the exact text, sorry - I can re-run it if it's important.) At that point I did Alt+Ctrl+F2, then chroot'ed to /mnt/sysimage as you suggested. Unfortunately grub2-efi-install is not on the search path, so I couldn't run it. (No programs starting with "grub2", in fact.) The un-chroot'd system has grub2 programs in /sbin, but not grub2-efi-install. I was hoping I could do yum install inside the chroot'd system, but the network is not set up at that point.

Following instructions here (https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#UEFI_Shell) I copied thex86_64 UEFI Shell 1.0 onto a USB flash drive, booted, pressed F10, selected the flash drive and got "Invalid system disk".

I thought perhaps there might be an ISO or something available that the system could boot from CD or flash drive, by whatever mechanism it's able to boot from some CD/DVDs now, that would then boot from the HDD in EFI mode -- basically substituting for my BIOS. rEFIt (http://refit.sourceforge.net/) sounded semi-promising for that -- I wasn't sure whether it was only for Intel Macs -- but when I wrote their "cdr" image to a CD and tried to boot, I still got "No bootable device".


FWIW, here is what I currently have in the ESP from the installation (and possibly with some fiddling from my experiments):


-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/BOOT/BOOT-64.efi
-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/microsoft/IA64LDR.efi
-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/microsoft/boot/IA64LDR.efi
-rw-r--r-- 1 root root 64 Feb 19 22:33 EFI/redhat/device.map
-rw-r--r-- 1 root root 64 Feb 19 19:24 EFI/redhat/device.map.anacbak
-rw-r--r-- 1 root root 442 Feb 19 22:33 EFI/redhat/grub.conf
-rw-r--r-- 1 root root 442 Feb 19 19:24 EFI/redhat/grub.conf.anacbak
-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/redhat/grub.efi


I thought about writing to Intel to ask what I'm missing here, but my board is past EOL.

Don3
23rd February 2012, 08:19 AM
So having pretty much given up on getting EFI boot to work on this board, and as it seems I can't go back to MBR boot since the necessary BIOS config settings won't stick any more, I tried one last configuration before springing for a new mainboard + CPU + RAM...

I went [back] to a custom partitioning configuration, using gdisk on SystemRecueCD to set it up. I created a BIOS boot partition and an EFI System Partition (just in case I ever got either one working again) and an ext4 /boot partition, then installed F16 using the network (minimal) CD. After finally getting through the installation successfully, the next boot-up gave me the now-familiar and expected "No bootable device", so I ran SystemRescue CD again, fixed the GUID partition types (see note below), mounted the root, boot partitions under a sub-dir of /mnt, chroot'd into the installation, ran grub2-install (although I may not have needed to do that), then booted with Super GRUB2 Disk (http://www.supergrubdisk.org/super-grub2-disk/) and used that to boot the F16 installation from disc. So from here on, it'll be an ugly 2-step boot procedure -- but luckily I rarely need to boot this machine, because it normally runs 24x7.

A few other observations along the way...

The Fedora install CD (and I believe DVD as well) starts up in two different ways, seemingly dependent on when the BIOS discovers them. If I insert the CD before the Intel splash screen appears, or possibly when it's first up, I get a menu with a night sky background and only one entry (Fedora 16), as I mentioned in an earlier post. But if I wait to insert the CD until just after the splash screen clears, I first get an interesting menu from the BIOS (see footnote [4] here (http://mjg59.dreamwidth.org/4957.html?thread=94301); selecting '1', I get a text-mode boot menu that has more options, including "troubleshooting", which you mentioned earlier.

It seems the text mode installer has an issue with existing LUKS encrypted partitions. It prompts for a passphrase but is never satisfied with the answer -- no complaints, but it just continually prompts for the passphrase on the same partition. The graphical installer works fine in this regard.

After carefully setting GUID partition types to what I thought they were supposed to be using gdisk, and then running the Fedora installer, I discovered that the installer had changed many of the partition types to, umm, different values. I didn't write them all down, but in one case, I had used 8300 (Linux filesystem) for the ext4 /boot partition, but the installer changed it to 0700 (Microsoft basic data).

Over the course of this adventure, I had tried different combinations of BIOS boot and EFI system partitions, "enabling" or "disabling" them by changing their GUID partition types (I figured changing them to a type like swap should effectively disable them), and/or selecting them or not in the GUI installer's partitioning screen. I found that the installer crashes with at least one combination (and with the BIOS set for EFI boot), but unfortunately I don't remember which one now. (My enthusiasm for careful note-taking decreased as the frustration level increased...) Having been through this, I'm thinking it would be really nice if the installer said what it was trying to do bootloader-wise, and possibly even give an "advanced" config screen. Also would be nice if the install CDs/DVDs included gdisk.

srs5694
23rd February 2012, 07:37 PM
Downloaded the full F16 install DVD. As with the minimal boot CD, the DVD's boot menu has only one choice, "Fedora 16", so I took that and ran through an "upgrade" installation. It seems to have recognized that there was nothing to do, but offered to install the bootloader. All looked well until the end when a dialog announced that the bootloader installation had failed and the machine might be unbootable. (I don't have the exact text, sorry - I can re-run it if it's important.) At that point I did Alt+Ctrl+F2, then chroot'ed to /mnt/sysimage as you suggested. Unfortunately grub2-efi-install is not on the search path, so I couldn't run it. (No programs starting with "grub2", in fact.) The un-chroot'd system has grub2 programs in /sbin, but not grub2-efi-install. I was hoping I could do yum install inside the chroot'd system, but the network is not set up at that point.

The installer's log files probably contain a clue about what went wrong. I don't recall precisely what they're called, but IIRC they're in the newly-installed system's /root directory. You could have a look for them....



I thought perhaps there might be an ISO or something available that the system could boot from CD or flash drive, by whatever mechanism it's able to boot from some CD/DVDs now, that would then boot from the HDD in EFI mode -- basically substituting for my BIOS. rEFIt (http://refit.sourceforge.net/) sounded semi-promising for that -- I wasn't sure whether it was only for Intel Macs -- but when I wrote their "cdr" image to a CD and tried to boot, I still got "No bootable device".


rEFIt can help cut through some problems with getting EFI boot loaders recognized, but it's a chicken-and-egg sort of problem -- rEFIt is basically just another boot loader, so you've got to get it recognized before it will help you load other boot loaders. Also, the version on the main rEFIt site you referenced won't work on UEFI PCs; that version uses a "fat" binary format (32-/64-bit) that works only on Macs. You can find a 64-bit-only version on my Web page on the topic. (http://www.rodsbooks.com/efi-bootloaders/refit.html)


FWIW, here is what I currently have in the ESP from the installation (and possibly with some fiddling from my experiments):


-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/BOOT/BOOT-64.efi
-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/microsoft/IA64LDR.efi
-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/microsoft/boot/IA64LDR.efi
-rw-r--r-- 1 root root 64 Feb 19 22:33 EFI/redhat/device.map
-rw-r--r-- 1 root root 64 Feb 19 19:24 EFI/redhat/device.map.anacbak
-rw-r--r-- 1 root root 442 Feb 19 22:33 EFI/redhat/grub.conf
-rw-r--r-- 1 root root 442 Feb 19 19:24 EFI/redhat/grub.conf.anacbak
-rw-r--r-- 1 root root 338312 Oct 26 22:29 EFI/redhat/grub.efi


I realize you said you started fresh in your next post, but instead of that first file, if you name a boot loader EFI/BOOT/BOOTX64.EFI (note: BOOTX64.EFI, not BOOT-64.EFI; case-insensitive), you should get something to begin booting. That's the default name for an EFI boot loader. Adding a boot loader to the EFI's list with efibootmgr should theoretically work, but in practice it sometimes doesn't.

Another point: Some boot loaders require configuration files in their main directories -- EFI/BOOT if you use the name I've just specified. For GRUB Legacy, the name is the same as the boot loader's binary file, but with a .CONF extension, so it would be BOOTX64.CONF if you use the default location and filename. Most other boot loaders use a fixed name, such as elilo.conf for ELILO, no matter what its binary is called.

EFI is supposed to make boot loader installation and maintenance easier, and in some cases it does. Unfortunately, some EFI implementations don't work the way they're supposed to work (or maybe efibootmgr is broken). Many EFI developers are stingy with boot loader options in their user interfaces, which makes it hard to get things running and harder for knowledgeable people to help others, since the options vary so much from one implementation to another.


The Fedora install CD (and I believe DVD as well) starts up in two different ways, seemingly dependent on when the BIOS discovers them. If I insert the CD before the Intel splash screen appears, or possibly when it's first up, I get a menu with a night sky background and only one entry (Fedora 16), as I mentioned in an earlier post. But if I wait to insert the CD until just after the splash screen clears, I first get an interesting menu from the BIOS (see footnote [4] here; selecting '1', I get a text-mode boot menu that has more options, including "troubleshooting", which you mentioned earlier.

You're probably seeing the difference between BIOS-mode and EFI-mode booting. IIRC, In BIOS mode, the Fedora installer uses the ISOLINUX boot loader, which is a BIOS-mode boot loader for optical discs. In EFI mode, OTOH, Fedora uses GRUB Legacy to boot its installer, since GRUB Legacy works fine on optical discs in EFI mode. This results in different boot-time menus and different options.

Note that the mode in which you boot affects whether efibootmgr will work at all; if you boot in BIOS mode, it won't work. For efibootmgr to be useful, you must boot in EFI mode.


After carefully setting GUID partition types to what I thought they were supposed to be using gdisk, and then running the Fedora installer, I discovered that the installer had changed many of the partition types to, umm, different values. I didn't write them all down, but in one case, I had used 8300 (Linux filesystem) for the ext4 /boot partition, but the installer changed it to 0700 (Microsoft basic data).

The gdisk 0x8300 code is a new Linux-specific type code that's not yet implemented by libparted, upon which the Fedora installer's partitioner is based. Thus, it'll get changed to what gdisk calls 0x0700, which is what Linux has traditionally used. This isn't a big deal for a Linux-only installation, since Linux ignores partition type codes for most purposes. If you're dual-booting with Windows, though, you'll want to change the type code of Linux filesystems after installing. If you don't, your Linux filesystem partition(s) will show up as unformatted disks in the Windows file manager, making it way too easy to trash your Linux installation from Windows. I've written a Web page on this topic. (http://www.rodsbooks.com/linux-fs-code/index.html)

FWIW, the parted developers have had a patch for months, and have said it would be incorporated into parted, but they've been inexplicably slow to do this. I've filed a bug report with Fedora, at https://bugzilla.redhat.com/show_bug.cgi?id=795206, so there's a chance that this patch will be added to the parted that ships with Fedora 17.

chrismurphy
23rd February 2012, 07:50 PM
Re: comment #11 19th February 2012, 11:23 PM

I find the .efi file sizes and dates suspicious. I don't know why all of these boot loaders are the exact same size. Anyway, I agree with Rod that BOOT-64.efi isn't going to work. I'd remove that, whatever it is, and copy grub.efi and grub.conf to /EFI/BOOT/ as BOOTX64.efi and BOOTX64.conf *and* grub.conf. I've variably found one or the other to work, and now I just do both. It wouldn't surprise me if the filename is baked into grub.efi and I'm confused because of the differences in how GRUB Legacy EFI and GRUB2 EFI work.*

Note that Fedora 16/17 are using Grub Legacy EFI, whereas for BIOS installations they use GRUB2. It's almost like insufflating sriracha.

srs5694
23rd February 2012, 08:28 PM
I hadn't noticed that the file sizes and dates are identical. That's probably the result of manual copying of files in an effort to get something to work.

FWIW, another thing I hadn't noticed on the first pass: The IA64LDR.efi filename sounds like it's for an Itanium CPU. On my UEFI Windows installation, the Windows boot loader is called BOOTMGFW.EFI. My suspicion is you copied another boot loader to this name based on some documentation that was intended for Itanium systems. If so, you should just delete the whole EFI/microsoft directory tree; it's worse than useless, since it can only result in confusion.

Don3
24th February 2012, 08:12 PM
Thanks very much to both of you for your replies!


The installer's log files probably contain a clue about what went wrong. I don't recall precisely what they're called, but IIRC they're in the newly-installed system's /root directory.


Yes, there are a couple log files there: install.log and install.log.syslog, Somehow I didn't think to look at them when I saw the earlier issues, and I've done another successful install since, so the contents of the logs don't look very interesting right now.

srs5694: I haven't tried your version of rEFIt yet. Hopefully I can get to that later today or tomorrow, but I wanted to give an update on the other things first...

First, my apologies for posting my ESP contents in that state. You're right that it was the result of several copying/renaming attempts, as I was fishing for some path that would entice the BIOS into biting, based on what I'd read in various places. At some point I tried other bootloaders, including an EFI shell. ATM I don't even remember what the one in that listing was. So yes, all I did was add confusion, sorry.

Starting from a clean installation, using custom partitioning and booting the install CD in EFI mode, the ESP contains just one file:


-rwx------ 1 root root 680960 Dec 9 11:38 EFI/redhat/grub.efi


Attempting to boot with that results in "No bootable device -- insert boot disk and press any key".

So I booted using the Super GRUB2 Disk (which boots in BIOS mode - but it provides a network connection, which the install CD does not, despite having gone through the host-name and "configure network" screen), mounted the F16 partitions, chroot'd into it, used yum to install grub2-efi and efibootmgr packages, and ran grub2-efi-install. After that, there were 2 files in the ESP


-rwxr-xr-x 1 root root 147456 Feb 23 21:31 EFI/fedora/grubx64.efi
-rwxr-xr-x 1 root root 680960 Dec 9 17:38 EFI/redhat/grub.efi


and efibootmgr (with no arguments) writes


BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux
Boot0001* fedora


which is also part of grub2-efi-install's output.

Result: "No bootable device -- insert boot disk and press any key"

Booting again from one of the CDs, I copied the fedora bootloader to the default path, giving:


-rwx------ 1 root root 147456 Feb 23 16:52 EFI/BOOT/bootx64.efi
-rwx------ 1 root root 147456 Feb 23 16:52 EFI/fedora/grubx64.efi
-rwx------ 1 root root 680960 Dec 9 11:38 EFI/redhat/grub.efi


Result: "No bootable device -- insert boot disk and press any key"

I didn't try copying in any .conf files yet, partly because there aren't any under /boot. There is one .cfg file, grub2/grub.cfg (not in grub2-efi, if that matters, although there is one in /etc), but I wasn't sure it was the same sort of thing that the bootloader might be looking for. I also figured that the "No bootable device" message was coming from the BIOS, meaning that I wasn't getting far enough yet to worry about config file issues. But I can try copying, say, /etc/grub2-efi.cfg as EFI/BOOT/bootx64.conf if you think it'd be a worthwhile experiment.

Thanks for the explanations about GPT types, and thanks for the great on-line docs! And while I'm at it, thanks for gdisk -- it makes more sense to me than parted, even aside from the missing patch issue. (I have a question or two about it, but I'll ask that somewhere else...) I wish it came with the install CD and DVD. Anyway, I'm pretty sure the types were changed on at least 2, maybe 3 partitions in addition to the 0700's on the ext4 partitions. I'll likely be doing at least one more clean install soon, so I'll try to remember to write that down next time.

srs5694
24th February 2012, 09:53 PM
Yes, there are a couple log files there: install.log and install.log.syslog, Somehow I didn't think to look at them when I saw the earlier issues, and I've done another successful install since, so the contents of the logs don't look very interesting right now.

If your system isn't booting (as it sounds like it isn't), then I'd say your install is not successful. Still, at least the main boot loader is in place and it sounds like your firmware isn't detecting it, so you may be right that there won't be any clues in the log files. OTOH, you might see an error message related to efibootmgr or the installation of the boot loader configuration files, so it's worth perusing them.


So I booted using the Super GRUB2 Disk (which boots in BIOS mode - but it provides a network connection, which the install CD does not, despite having gone through the host-name and "configure network" screen), mounted the F16 partitions, chroot'd into it, used yum to install grub2-efi and efibootmgr packages, and ran grub2-efi-install. After that, there were 2 files in the ESP


-rwxr-xr-x 1 root root 147456 Feb 23 21:31 EFI/fedora/grubx64.efi
-rwxr-xr-x 1 root root 680960 Dec 9 17:38 EFI/redhat/grub.efi


and efibootmgr (with no arguments) writes


BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux
Boot0001* fedora


If you're running this after booting from Super GRUB 2 Disk, then it suggests that you booted in EFI mode, not BIOS mode. You can check this by examining your kernel ring buffer with dmesg:



dmesg | grep EFI


An EFI boot will produce many lines, as in:



[ 0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[ 2.514042] efifb: probing for efifb
[ 2.514823] efifb: framebuffer at 0xc0000000, mapped to 0xffffc90011a00000, using 3752k, total 32704k
[ 2.514829] efifb: mode is 800x600x32, linelength=3200, pages=1
[ 2.514833] efifb: scrolling: redraw
[ 2.514837] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
rodsmith@seeker:/other/nessus/homepage/parted-patches$ dmesg | grep EFI
[ 0.000000] Command line: BOOT_IMAGE=atapi0:\EFI\ELILO\bzImage-3.0.4 root=/dev/seeker/u1104 ro
[ 0.000000] EFI v2.00 by American Megatrends
[ 0.000000] Kernel-defined memdesc doesn't match the one from EFI!
[ 0.000000] EFI: mem00: type=3, attr=0xf, range=[0x0000000000000000-0x0000000000048000) (0MB)
[ 0.000000] EFI: mem01: type=7, attr=0xf, range=[0x0000000000048000-0x0000000000097000) (0MB)
...
[ 0.000000] EFI: mem135: type=11, attr=0x8000000000000001, range=[0x00000000ff000000-0x0000000100000000) (16MB)
[ 0.000000] Kernel command line: BOOT_IMAGE=atapi0:\EFI\ELILO\bzImage-3.0.4 root=/dev/seeker/u1104 ro
[ 2.517097] fb0: EFI VGA frame buffer device
[ 3.174283] EFI Variables Facility v0.08 2004-May-17
[ 9.386613] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver


I've trimmed many of those lines for brevity; there are "EFI: mem00" through "EFI: mem135" lines, plus the others. Details will vary, of course. On a non-EFI system, though, you're likely to get no output from this command, or perhaps just a few lines, perhaps with "EFI" matching some larger string.


Result: "No bootable device -- insert boot disk and press any key"

Your efibootmgr output looks reasonable. I have some suggestions at this point to get EFI booting working:


Go into the firmware setup utility and look for options related to EFI booting and play with them. On my Intel DG43NB motherboard (which presumably has a similar UEFI implementation), there's a firmware option to enable/disable EFI-style booting under the "Boot" menu. Be sure that EFI-style booting is enabled. You can also experiment with other options on this menu, assuming your firmware is similar to mine.
Pressing F10 at boot time brings up a boot selector that gives you the choice of which EFI boot option to select. (For you, it should include both "Linux" and "fedora," if your efibootmgr output is accurate.)
Examine the first sector of your hard disk. If it contains BIOS boot loader code, it's conceivable that your firmware is detecting that, switching to BIOS mode, and failing to boot because the boot loader is incomplete. If you find this is the case, you can wipe it clean with the command "dd if=/dev/zero of=/dev/sda bs=440 count=1". Be sure to get the device filename, bs=, and count= options right, or you might wipe out the wrong disk or more than you intend!
Check the EFI System Partition (ESP) on the computer. Be sure it's got the right type code -- 0xEF00 in gdisk or a "boot flag" in parted. Also verify that it's FAT32. Another point: I vaguely recall hearing about a UEFI implementation that has problems if the ESP is too big, and Fedora tends to create huge ESPs (tens of gigabytes). My own recommendation is to make it 200-500 MiB in size.



I also figured that the "No bootable device" message was coming from the BIOS, meaning that I wasn't getting far enough yet to worry about config file issues. But I can try copying, say, /etc/grub2-efi.cfg as EFI/BOOT/bootx64.conf if you think it'd be a worthwhile experiment.

This is probably a correct assessment; IIRC, GRUB Legacy and GRUB 2 both give other messages if they can't load relevant code or find their configuration files. I might be mistaken about this, though.

---------- Post added at 03:53 PM ---------- Previous post was at 03:48 PM ----------

Oh, one more thing I forgot: If booting in EFI mode proves to be too hairy, you can probably revert to BIOS mode. To do this, you'd disable EFI booting in the BIOS. You could then wipe the disk and re-install or boot in BIOS mode and install a BIOS-type boot loader. The Intel motherboard firmware is likely to have problems booting from GPT if the protective MBR's 0xEE partition is not flagged as bootable, though, so if you stick with GPT and switch to BIOS booting, you should set the boot flag using fdisk (not gdisk or parted!).

Don3
25th February 2012, 04:40 AM
If your system isn't booting (as it sounds like it isn't), then I'd say your install is not successful.


I'm with you on that. :) What I meant in this case was that the installer seemed satisfied with what it had done ("Installation successful, please reboot to finish the installation", or some such), whereas with some of my other attempts, it failed on the BL installation or just crashed. I'm starting to understand possible reasons for that now, thanks largely to the help I've received here. Indeed the system does not boot on its own, but I've been able to boot it using the CDs I've mentioned.




So I booted using the Super GRUB2 Disk (which boots in BIOS mode...), mounted the F16 partitions, chroot'd into it, used yum to install grub2-efi and efibootmgr packages, and ran grub2-efi-install. After that, there were 2 files in the ESP ... and efibootmgr (with no arguments) writes ...

If you're running this after booting from Super GRUB 2 Disk, then it suggests that you booted in EFI mode, not BIOS mode.

Woops! You're quite right! Full disclosure: I wrote the previous post twice. Just as I was about to hit the submit button the first time, my browser crashed, taking the entire thing with it. On my second attempt, I skipped over some important details, sorry. Here's something closer to the complete sequence:

booted using the Super GRUB2 Disk
mounted the F16 partitions
chroot'd into F16 root dir
used yum to install grub2-efi and efibootmgr packages
shut down
booted using the F16 install CD in EFI mode
proceded past the network setup (not that it does any good)
mounted the F16 partitions
chroot'd into F16-land
ran grub2-efi-install
looked at the contents of /boot/efi/...


I'm pretty sure the Super Grub2 disk is booting in BIOS mode because efibootmgr fails if I try to use it when the system was booted that way, "modprobe efivars" fails, etc. But one interesting thing to me is that the BIOS seems to be capable of booting the Fedora install CD/DVD in either mode - although so far the only way I've discovered to control it is to change when I insert the disc relative to what I see on the screen. Sure would be nice if the BIOS would say what it's trying to do.




Go into the firmware setup utility and look for options related to EFI booting and play with them. On my Intel DG43NB motherboard (which presumably has a similar UEFI implementation), there's a firmware option to enable/disable EFI-style booting under the "Boot" menu. Be sure that EFI-style booting is enabled. You can also experiment with other options on this menu, assuming your firmware is similar to mine.


Yes, my board has an "EFI boot" option, which is either enabled or disabled. Er, well, in my case enabled is the only choice that sticks - I can change the setting to disabled, but after saving the settings and booting again, it reverts to enabled. I've checked the so-called "CMOS" battery (3.2 volts), and I've tried disconnecting all HDDs, just to make sure the BIOS wasn't setting EFI mode based on seeing a GPT. Beyond the one enable/disable parameter, I don't see any other EFI-related options, and I don't even see any mention of EFI in Intel's BIOS "glossaries".




Pressing F10 at boot time brings up a boot selector that gives you the choice of which EFI boot option to select. (For you, it should include both "Linux" and "fedora," if your efibootmgr output is accurate.)


The menu items are:

fedora
Linux
HP DVD Writer 640
P0-ST31000528AS

Selecting "fedora" clears the screen, code BA shows in the lower right for a couple seconds, then the F10 screen returns - and "fedora" is no longer in the list! Selecting "Linux" elicits a similar response, except that the code is BB. (The copy of Intel's BIOS doc I have lists POST code BA as "Detecting presence of a removable media (IDE, CD-ROM detection, etc.)", and BB is not documented. So maybe these aren't POST codes...) Selecting either of the other two remaining entries boots an optical disc, if there's on in the drive, otherwise it's my old favorite "No bootable device...".



Examine the first sector of your hard disk. If it contains BIOS boot loader code, it's conceivable that your firmware is detecting that, switching to BIOS mode, and failing to boot because the boot loader is incomplete. If you find this is the case, you can wipe it clean with the command "dd if=/dev/zero of=/dev/sda bs=440 count=1". Be sure to get the device filename, bs=, and count= options right, or you might wipe out the wrong disk or more than you intend!


Excellent idea... There was indeed code in the first part of the MBR -- I saved a copy before I wiped those first 440 bytes -- and I could see the "protective" partition entry there too. I can send you hex dumps of the "before" and "after" contents if needed. However, zeroing those bytes had no effect on the behaviour.



Check the EFI System Partition (ESP) on the computer. Be sure it's got the right type code -- 0xEF00 in gdisk or a "boot flag" in parted. Also verify that it's FAT32. Another point: I vaguely recall hearing about a UEFI implementation that has problems if the ESP is too big, and Fedora tends to create huge ESPs (tens of gigabytes). My own recommendation is to make it 200-500 MiB in size.


Yes, the ESP has type 0xEF00, and the size is within your recommend range. Here are the first few partitions currently set up (gdisk output):


Number Start (sector) End (sector) Size Code Name
1 40 2047 1004.0 KiB 8301 Linux reserved
2 2048 788479 384.0 MiB EF00 EFI System Partition
3 788480 1574911 384.0 MiB 8300 boot
4 1574912 51906559 24.0 GiB 8300 root

Of course this is not the default Fedora layout. FYI, I put partition 1 there only to allow for experiments with a BIOS boot partition, back when I was thinking that might be a possibility. It's all 0x00's at the moment.

The ESP was mounted with type "vfat", and at first I wasn't sure which type of FAT it was, until I noticed this in the output of fsck.vfat (dosfsck):


First FAT starts at byte 8192 (sector 16)
2 FATs, 16 bit entries
98304 bytes per FAT (= 192 sectors)

This was created by the installer, AFAIK. I don't know how it's being called, but I noticed in the man page for mkdosfs that by default it chooses the FAT size based on the size of the file system, and this one isn't huge... So I made a cpio archive of the contents, unmounted it, created a new FAT32 file system, and restored the contents from the archive.

Result: "No bootable device -- insert boot disk and press any key"


If booting in EFI mode proves to be too hairy, you can probably revert to BIOS mode. To do this, you'd disable EFI booting in the BIOS...

If only we could cure the board of its current aversion to that option. It booted that way for over 4 years, but it seems disinclined to do that now.

chrismurphy
25th February 2012, 04:57 AM
-rwx------ 1 root root 147456 Feb 23 16:52 EFI/BOOT/bootx64.efi


I don't know that it matters, but I've always found references that this should be BOOTX64.efi not bootx64.efi.

That the EFI firmware is not finding this, is confusing. I'm increasingly thinking you've got a firmware bug. AFAIK, the UEFI spec doesn't require the EFI system partition be the very first partition, so your firmware should find it based on reading the GPT, should know how to read the FAT32 variant of the EFI file system format, and always consume any file with this name in this path. That it's not...highly suspect.




Number Start (sector) End (sector) Size Code Name
1 40 2047 1004.0 KiB 8301 Linux reserved
2 2048 788479 384.0 MiB EF00 EFI System Partition
3 788480 1574911 384.0 MiB 8300 boot
4 1574912 51906559 24.0 GiB 8300 root


a. The first partition type code should be EF02 not 8301.

b. I'm confused how this 1st partition starts at sector 40.The only tool I know that starts partitions at sector 40 is Apple's Disk Utility. Everything else starts them at either 63 or 2048. Assuming you created this manually.

c. Partition 2, EFI System should be 200MiB. 384 is overkill.

d. Partition 3, /boot is normally 500MB.

e. I personally would have the first partition start at 2048 and be the EFI System partition, followed by the BIOS Boot partition, followed by /boot and then /.

Don3
25th February 2012, 05:52 AM
Originally Posted by Don3

-rwx------ 1 root root 147456 Feb 23 16:52 EFI/BOOT/bootx64.efi


I don't know that it matters, but I've always found references that this should be BOOTX64.efi not bootx64.efi.

AFAIK it isn't case sensitive, and I think srs5694 said that earlier too. But I can give it a try like that.


I'm increasingly thinking you've got a firmware bug.

Yeah, I've been wondering about that too. I did upgrade to the latest BIOS release, which was like 2009-ish, IIRC. Since EFI originated with Intel, I was hoping the BIOS on an Intel board might implement it fairly close to "correctly", whatever that meant at the time. Also the fact that (at least some) BIOS settings don't stick any more makes me wonder whether there's a HW problem.


a. The first partition type code should be EF02 not 8301.
Yes, and it was EF02 until just a little while ago. I was just trying to make sure the BIOS wasn't confused by the presence of a BIOS boot partition, even though there's no file system in it, so I set the type to something else. It had no effect though.


b. I'm confused how this 1st partition starts at sector 40.The only tool I know that starts partitions at sector 40 is Apple's Disk Utility. Everything else starts them at either 63 or 2048. Assuming you created this manually.

Indeed, I did this one manually. Earlier in the thread I was using the installer's default partitioning scheme. That didn't work either, but then I have made a few changes since then, so I suppose I should retest that. Oh, I chose to start on sector 40 because it's the first 4-KiB-aligned sector after the primary GPT.



c. Partition 2, EFI System should be 200MiB. 384 is overkill.

d. Partition 3, /boot is normally 500MB.

e. I personally would have the first partition start at 2048 and be the EFI System partition, followed by the BIOS Boot partition, followed by /boot and then /.

The sizes I chose were more or less initial guesses, not knowing how all this was going to work out. The installer's default arrangement gave me a 35-GiB(!) ESP (see post #4 (http://forums.fedoraforum.org/showpost.php?p=1553087&postcount=4)), so I guess I'm more reasonable than that. Also the default configuration has no BIOS boot partition at all, and I was thinking I should have one for experimentation purposes, if nothing else. ATM there's no point in me having one, since I can't seem to boot in BIOS mode any more.

chrismurphy
25th February 2012, 07:38 AM
I would like to think a 2009 UEFI from Intel would behave pretty well. But what do I know?

Boot off anything other than the hard drive.

dd if=/dev/zero of=/dev/sda bs=1M count=1

Yank the batteries on the motherboard, and the power cable between motherboard and power supply. Let it sit overnight. Play again in the morning. Maybe something in NVRAM is fakaked, or elsewhere on that board.

Start with EFI/BIOS and seeing if you can get it to stick in EFI mode. Chances are, after restoring batteries and power, it reverts to default BIOS emulation (?). I'd also stick to just F16 DVD or LiveCD.

Do a default installation. Even odds whether it will boot or not. Again, I'm not sure if this UEFI has a boot selection menu, that would compel it to scan EFI//EFI/ for boot loaders. So you may still have to boot off a LiveCD and populate EFI//EFI/BOOT with a renamed grub.efi and grub.conf.

But at this point, in theory, you'd have started with clean NVRAM, clean first 1MB of the disk, clean GPT with default partitioning, and maybe a single modification to make EFI//EFI/BOOT/BOOTX64.efi

If that doesn't work... I think you're stuck in a rabbit hole. You could start over yet again, blow away the first 1M, reset the NVRAM, confirm you're back in BIOS emulation mode, and then do a new install. One of them's got to work, or you're right - wonky motherboard more likely than firmware.

Hey, have you tried doing a few passes of memtest86? Might be worth a go overnight.

srs5694
26th February 2012, 07:56 AM
Sorry for the delay in posting. I've had my own problems -- my primary system's motherboard died suddenly on Friday evening, so I couldn't replace it until today, and the replacement (a Gigabyte board) has an EFI implementation that makes Intel's primitive one look advanced.

Anyhow, a few comments:


The size of the ESP is somewhat arbitrary. The key is that it be big enough to hold necessary drivers, boot loaders, and other files, but not so big that it's wasting space. Since ELILO more-or-less requires that the kernel and initial RAM disk be stored on the ESP, that makes the size requirements similar to those for a separate /boot partition if you think you might want to use ELILO. Since ELILO is, in my experience, the most reliable EFI boot loader for Linux (followed closely by GRUB Legacy), IMHO, something in the 200-500 MiB range is good for the ESP.
You might want to try again with the ESP as the first partition. This shouldn't make a difference, but who knows, maybe there's a bug in your firmware that makes an assumption about the partition number of the ESP. (You can use gdisk to transpose partition numbers, which might be a quick way to test at least part of this -- transpose partitions 1 and 2 to make the ESP partition #1 in the table, although it'll still come second in terms of allocated disk sectors.)
I agree with Chris's suggestions for trying to wipe your CMOS as clean as possible in case some setting is lingering there despite the usual cleaning-out procedures.
Now that I think about it, I have a vague memory that my Intel board's EFI implementation might have ignored the EFI/BOOT/BOOTX64.EFI default EFI boot loader file, too, so your results on that score may not be abnormal in terms of what's normal for Intel's boards. (The EFI spec does say that an EFI firmware must load that file as a default, IIRC, so this indicates a deviation from the spec.)
Have you tried booting in BIOS mode (via Super GRUB Disk or something similar) and installing GRUB Legacy or GRUB 2 in that mode? (My apologies if you've already said you've tried this. I don't recall your mentioning it, and nothing jumped out in a quick scan of earlier posts.) If you do this, wipe the ESP, and give it a new type code, that might convince the firmware to look for a BIOS-style boot loader. (Note that you may need to set the bootable flag on the 0xEE MBR protective partition or the Intel firmware may refuse to boot from the disk in BIOS mode.)
Could you boot the installer in EFI mode, type "efibootmgr -v", and post the results here? (After adding new EFI boot manager entries, if necessary.) Perhaps we'll spot some subtle error, like a mis-specified path to the boot loader files.
It should be possible to create an EFI-bootable CD that would launch GRUB, ELILO, or rEFIt. (The rEFIt CD image on its main site won't work because that uses a Mac "fat binary" that UEFI systems can't parse.) I've been meaning to do something like this with rEFIt for a while, but haven't gotten around to it yet....


---------- Post added at 01:56 AM ---------- Previous post was at 12:57 AM ----------

OK, I've made a first pass at a UEFI-capable CD-R image with rEFIt. I've posted it on my Web site here:

http://www.rodsbooks.com/efi-bootloaders/refit-cd.iso.gz

If you care to try it, I'd be interested in hearing how it works. (So far I've only tested it in a VirtualBox session myself.)

Don3
27th February 2012, 06:47 AM
Originally posted by chrismurphy

Boot off anything other than the hard drive.

dd if=/dev/zero of=/dev/sda bs=1M count=1

Yank the batteries on the motherboard, and the power cable between motherboard and power supply. Let it sit overnight. Play again in the morning. Maybe something in NVRAM is fakaked, or elsewhere on that board.


I don't think I mentioned it here before, but I tried this earlier -- left the battery out for over a day, shorted the battery contacts (to make sure any capacitance got discharged) wiped the whole drive, and even unplugged it. I can certainly try it again though.



Start with EFI/BIOS and seeing if you can get it to stick in EFI mode. Chances are, after restoring batteries and power, it reverts to default BIOS emulation (?).


Getting it to stick in EFI mode is not a problem -- it only sticks in EFI mode. My previous attempt with removing the battery etc had no effect on that. But as I say, it may be worth another shot -- ya never know...



Do a default installation. Even odds whether it will boot or not.


Previous attempts using default partitioning fared no better, I'm afraid. (I talked about one of them starting with post #4 (http://forums.fedoraforum.org/showpost.php?p=1553087&postcount=4).) But I can try this again too.



Again, I'm not sure if this UEFI has a boot selection menu, that would compel it to scan EFI//EFI/ for boot loaders.


I've learned during the course of this that it does have a menu that's displayed if F10 is pressed while on the Intel splash screen, but the menu behaves very strangely -- see post #11, 4th bullet (http://forums.fedoraforum.org/showpost.php?p=1556475&postcount=11) and the 2nd bullet list in post #18 (http://forums.fedoraforum.org/showpost.php?p=1557695&postcount=18).



Hey, have you tried doing a few passes of memtest86? Might be worth a go overnight.


Very good idea -- I haven't run that since I upgraded the RAM from 4 to 8 GiB a couple months ago. So I ran it overnight last night -- it did 3 full passes with no errors. Not sure the BIOS code uses the same RAM that memtest86 tests, but definitely good to rule out any obvious issues there.



Originally posted by srs5694

The size of the ESP is somewhat arbitrary. The key is that it be big enough to hold necessary drivers, boot loaders, and other files, but not so big that it's wasting space. Since ELILO more-or-less requires that the kernel and initial RAM disk be stored on the ESP, that makes the size requirements similar to those for a separate /boot partition if you think you might want to use ELILO. Since ELILO is, in my experience, the most reliable EFI boot loader for Linux (followed closely by GRUB Legacy), IMHO, something in the 200-500 MiB range is good for the ESP.


OK, good to know. That's pretty much what I had learned here and from the various docs I've read, including yours. :) I'd be happy to give ELILO a try (I remember using LILO for years before GRUB came along), but from what I can see at this point, the BIOS doesn't seem to recognize any EFI BL.




You might want to try again with the ESP as the first partition....


Good idea. I tried that, using gdisk to transpose partitions 1 and 2, as you suggested. No change in behaviour, unfortunately.




Now that I think about it, I have a vague memory that my Intel board's EFI implementation might have ignored the EFI/BOOT/BOOTX64.EFI default EFI boot loader file, too, so your results on that score may not be abnormal in terms of what's normal for Intel's boards. (The EFI spec does say that an EFI firmware must load that file as a default, IIRC, so this indicates a deviation from the spec.)


It would be great if we could dump the contents of the BIOS flash, and scan it for strings that look like paths... It'd really be ironic if a BIOS on an Intel board didn't follow the spec.




Have you tried booting in BIOS mode (via Super GRUB Disk or something similar) and installing GRUB Legacy or GRUB 2 in that mode?


I think I've tried it, more or less unintentionally, with some of my attempts early on - when I didn't really understand that the install CD/DVD could itself be booted in either mode. I can try it deliberately, but it may take a while -- I'll post the results of the next item first.




Could you boot the installer in EFI mode, type "efibootmgr -v", and post the results here? (After adding new EFI boot manager entries, if necessary.) Perhaps we'll spot some subtle error, like a mis-specified path to the boot loader files.


Here's the initial output I had:


BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux HD(1,800,479e000,166c2d13-514c-4921-9969-5f9e4cfaa823)File(\EFI\redhat\grub.efi)
Boot0001* fedora HD(2,800,c0000,e3ad4b9f-b0e5-431d-9fa7-8e387fceacac)File(\EFI\fedora\grubx64.efi)

I noticed that (what I assume were) the HD partition numbers in the two entries were different, which seemed odd -- and it occurred to me that I just transposed partitions, so I ran grub2-efi-install aain. Now "efibootmgr -v" reports:


BootCurrent: FFFF
BootOrder: 0001,0000
Boot0000* Linux HD(1,800,479e000,166c2d13-514c-4921-9969-5f9e4cfaa823)File(\EFI\redhat\grub.efi)
Boot0001* fedora HD(1,800,c0000,e3ad4b9f-b0e5-431d-9fa7-8e387fceacac)File(\EFI\fedora\grubx64.efi)





It should be possible to create an EFI-bootable CD that would launch GRUB, ELILO, or rEFIt. ... I've been meaning to do something like this with rEFIt for a while, but haven't gotten around to it yet....

OK, I've made a first pass at a UEFI-capable CD-R image with rEFIt. I've posted it on my Web site here:

http://www.rodsbooks.com/efi-bootloaders/refit-cd.iso.gz

I've been curious about optical media and USB flash devices since I came to understand (during the course of this) that the F16 install CD and DVD could be booted in either BIOS or EFI modes. I tried using ISOLINUX to make a CD version of your rEFIt contents, hacking in the MBR BL contents from the F16 CD and manually providing dummy MBR partition data. I can get ISOLINUX to come up, but I assume that's starting in BIOS mode. So far Google hasn't been much help in telling me how Fedora CD/DVD images are constructed.

I burned your ISO to a CD, and it works! That is, it comes up with rEFIt's menu. I tried clicking the two big icons on top, but they don't boot anything. One seems to re-load the rEFIt bootloader, and the other one clears the screen - nothing happens until I press a key, at which time it returns to the rEFIt menu. But hey, at least the CD boots -- that's better than what I had!

I'll post back when I have results from some of the other suggestions above. I may not have much chance to work on this during the next couple days...

chrismurphy
27th February 2012, 06:59 AM
The code blocks appear identical for:
"Here's the initial output I had:"
"Now "efibootmgr -v" reports:"

In both cases it appears the boot order is asking EFI to look for the 0001 entry which is:
File(\EFI\fedora\grubx64.efi

And I don't remember seeing that in any of your EFI System Partition listings. So that would seem to be a possible explanation for boot failure. I'm not sure why it doesn't fall back to the 0000 entry which you do have. But I might not be understanding the expected behavior.

Don3
27th February 2012, 07:29 AM
The code blocks appear identical for:
"Here's the initial output I had:"
"Now "efibootmgr -v" reports:"

In both cases it appears the boot order is asking EFI to look for the 0001 entry which is:
File(\EFI\fedora\grubx64.efi


The difference is in the first number in the parens, after "HD" in the "fedora" line, which I assume is the partition number.



And I don't remember seeing that in any of your EFI System Partition listings.


Isn't that what I have in post #16 (http://forums.fedoraforum.org/showpost.php?p=1557615&postcount=16)?:



-rwxr-xr-x 1 root root 147456 Feb 23 21:31 EFI/fedora/grubx64.efi
-rwxr-xr-x 1 root root 680960 Dec 9 17:38 EFI/redhat/grub.efi


Or do you mean that the leading [back]slash is a problem? Or have my eyes gone too blurry to see the difference?

chrismurphy
27th February 2012, 07:38 AM
No, it's just that I didn't remember it and was too lazy to go looking for it in a 25 post thread.

Well...I'm kinda stumped. Seems like the nvram contains the right info, but it still won't eat the grub.efi bootloader file. Wonky.

srs5694
27th February 2012, 04:33 PM
One thing I noticed about the efibootmgr output is that the two entries have different partition GUIDs -- 166c2d13-514c-4921-9969-5f9e4cfaa823 for the redhat entry and e3ad4b9f-b0e5-431d-9fa7-8e387fceacac for the fedora entry. This probably happened because of partition table changes. I'm not sure if your system would boot if the GUID doesn't match that of your current ESP. You can learn that GUID from gdisk's "i" command or via sgdisk:



sgdisk -i 1 /dev/sda


This assumes the disk is /dev/sda and the ESP's partition number is 1; change both as necessary. The result is on the "Partition unique GUID" line. If your current disk's ESP has a different GUID than the one for whatever boot loader you're trying to load, it's worth deleting the current entries and creating new ones using efibootmgr.

The fact that you got my rEFIt CD to boot is encouraging, even if it didn't do anything useful. I've got another version up that may provide another step toward a solution, if the GUID issue doesn't lead anywhere:

http://www.rodsbooks.com/efi-bootloaders/refit-cd2.iso.gz

Here's an image of what it should look like, for reference, although the first row of icons is likely to differ for you:

http://www.rodsbooks.com/efi-bootloaders/screenshot.png

To understand this, first note the text on the bottom line -- "Boot EFI\boot\bootx64.efi from" in the figure. This tells you precisely what file rEFIt will try to boot. The text changes when you move over the different icons. Note that rEFIt includes icons for both EFI-style and BIOS-style boots, although the BIOS-style boots only work on Macs, AFAIK.

The first row of icons represent EFI boot loaders or BIOS code that rEFIt thinks it can boot. The icons change depending on the type of OS that rEFIt thinks it's detected. You can move between options to see what you've got, and whether any of them match the files on your ESP. If they don't, that could be a clue -- perhaps there's filesystem damage that's preventing the firmware from reading the file, for instance.

The second row of icons represents non-bootloader actions. The new version of the rEFIt CD I've posted includes a new icon. It's the one on the far left, and the text should change to "Start EFI Shell" when you've selected it. This launches an EFI shell at which you can type commands. It's similar to a DOS prompt or Linux bash shell; you can use it to type commands ("ls", "cd", and so on) and launch programs -- EFI boot loaders. To start, try the following and see what you get:



fs0:
ls


This shows you what's on the first filesystem, which is probably the ESP. If you get an error or see some other partition's files, try "fs1:" rather than "fs0:". If you see your ESP's files, try:



cd EFI\fedora
ls
grubx64


This should show you the files in the Fedora boot loader directory and then launch that boot loader. If the files are missing, then that suggests filesystem corruption. If you see an error message, it might be helpful. You can try the same thing with the boot loader in the EFI\redhat directory, of course.

FWIW, the CD image is a stock ISO-9660 image with El Torito support. Put the contents of an ESP in the El Torito image and it's good to go -- but you'll only be able to boot from the EFI\boot\bootx64.efi file. Thus, you can experiment with this yourself, if you know how to create an El Torito image. With any luck, you'll learn something from the EFI shell that will be helpful in getting the disk to boot, but if not, it may be possible to create a bootable CD-R that starts up GRUB directly, rather than going through Super GRUB Disk.

Good luck!

Don3
29th February 2012, 08:38 AM
So, starting over...


Wiped the entire drive with 0x00s, disconnected it, disconnected the power supply, removed the battery, shorted the battery socket contacts with a jumper, and let it sit like that for 8 hours, maybe more.
Reconnected the PS, powered up, hit F2. UEFI boot is enabled from the start (which is consistent with the previous time I tried this). Disabled UEFI boot and hit F10 (save and exit), causing reboot.
Hit F2 again, checked UEFI boot : enabled again (also like before) -- ie, the setting did not stick.
Installed new 64-GB SSD instead of 1-TB HDD (for faster failures ;) ). Verified first and last 10 MB or so of SSD were all 0x00's.
Installed using Fedora 16 DVD, default partitioning, local repos only (for speed). Installation successful; on reboot: "No bootable device...".
Reset and re-load installation DVD, update existing installation, selected re-install bootloader option. Ran successfully, but on reboot: "No bootable device...".
Thought I would try running grub-efi-install manually, but it wasn't present. (2 RPMs starting with "grub" were installed: grubby and grub-efi.)
Booted System Rescue CD, mount F16 partitions, chroot, install grub2-efi. yum reported conflicts from grub-efi, so I had to remove that first. (I don't remember having to do that with the previous installation.)
Booted F16 install CD and ran grub2-efi-install. Ran successfully, but on reboot: "No bootable device...".
Booted F16 install CD again. fsck.vfat reported that the ESP is FAT32. (Previous installation, from CD, created this as FAT16.)
Copied EFI/fedora/grubx64.efi to EFI/BOOT/BOOTX64.efi.
Used efibootmgr to change from this


BootCurrent: FFFF
BootOrder: 0002,0001,0000
Boot0000* Linux HD(1,800,479e000,166c2d13-514c-4921-9969-5f9e4cfaa823)File(\EFI\redhat\grub.efi)
Boot0001* fedora HD(1,800,c0000,e3ad4b9f-b0e5-431d-9fa7-8e387fceacac)File(\EFI\fedora\grubx64.efi)

(ie, it seems 0000 might have been left over from previous installation) to this


BootCurrent: FFFF
BootOrder: 0001,0002
Boot0001* fedora HD(1,800,48c800,20f84020-f248-41cf-8065-93bc43237b17)File(\EFI\fedora\grubx64.efi)
Boot0002* Linux HD(1,800,48c800,20f84020-f248-41cf-8065-93bc43237b17)File(\EFI\BOOT\BOOTX64.efi)

Also tried setting a different label for 0002, but it would not take -- immediately echo'd back as "Linux".
Reboot: "No bootable device...".
Booted with Super GRUB2 Disk. It found no GRUB cfg's to boot. (This worked with the previous installation.)
Booted refit-cd2. Looked good, but I have only the far left and far right top-row icons (CDs, no HDDs). Clicking them gives same results as with previous version. Clicked on shell icon in bottom row. Screen cleared, after a few seconds got this [entered by hand, sorry for any mistakes]


ASSERT_EFI_ERROR (Status = Not Found)
ASSERT c:\dev\edk2tip\MdeModulePkg\Library\UefiHiiService sLib\UefiHiiServicesLib.c(88): !EFI_ERROR (Status)

No shell prompt -- had to use HW reset from there.


Interesting that the rEFIt CD is standard ISO-9660 with El Torito. I don't have much experience with El Torito, but for my attempt (a couple posts back) I believe I followed the instructions for SYSLINUX. But then I wasn't sure whether SYSLINUX was EFI-aware. How are you adding the El Torito support?

---------- Post added at 01:38 AM ---------- Previous post was at 01:20 AM ----------

Sorry, forgot to give the new partition layout, from the default installation:


Number Start (sector) End (sector) Size Code Name
1 2048 4771839 2.3 GiB EF00 EFI System Partition
2 4771840 5795839 500.0 MiB 0700
3 5795840 125044735 56.9 GiB 8E00

So a much smaller ESP than previously, though still quite a bit larger than it needs to be.

And current file contents of ESP:


-rwxr-xr-x 1 root root 147456 Feb 29 03:31 EFI/BOOT/BOOTX64.efi
-rwxr-xr-x 1 root root 147456 Feb 29 03:31 EFI/fedora/grubx64.efi
-rwxr-xr-x 1 root root 64 Feb 28 19:01 EFI/redhat/device.map
-rwxr-xr-x 1 root root 64 Feb 28 14:48 EFI/redhat/device.map.anacbak
-rwxr-xr-x 1 root root 771 Feb 28 19:01 EFI/redhat/grub.conf
-rwxr-xr-x 1 root root 771 Feb 28 14:48 EFI/redhat/grub.conf.anacbak
-rwxr-xr-x 1 root root 680960 Dec 9 17:38 EFI/redhat/grub.efi

srs5694
29th February 2012, 04:37 PM
Comments and observations about your latest attempt:


Have you tried flashing a new firmware image? Even if it's the same version you're running now, that might improve matters if your firmware has become damaged in some way.
Going a bit further, if the board has a socketed EEPROM chip, you could replace it with a new one in case it's become physically damaged.
The failure to launch the shell from rEFIt suggests a very serious error. I don't recognize the error message you got, but it makes me think your firmware has become corrupted. That's a very tentative conclusion, though.
I've posted a new version of my rEFIt boot CD. There's now a download link at http://www.rodsbooks.com/efi-bootloaders/refit.html. It differs in a couple of ways from the version you've got, one of which might conceivably produce better boot options, although I'm not very hopeful about that.
See this page (http://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI) for information on creating EFI-bootable disks. I'm still working through the details myself, and the images I've created so far include just one image rather than the two (for BIOS and EFI modes) described on that page.
Since you are able to boot from the CD in EFI mode, it should be possible to create a bootable CD with a Linux boot loader (GRUB Legacy, GRUB 2, or ELILO) to get your computer booted a little more directly than is possible with Super GRUB Disk.
Have you tried booting a USB flash drive in EFI mode? In theory, you can set one up with GPT and an ESP and toss boot loaders on it. If it works, it'd be a little easier to experiment with than a bootable CD.


---------- Post added at 10:37 AM ---------- Previous post was at 10:21 AM ----------

Update: I was going to try preparing a proof-of-concept Linux bootloader CD image, but it might be simpler/better for you to do it yourself:


Create a "scratch" directory and cd into it.
Type "dd if=/dev/zero of=efi.img bs=1048576 count=5". This creates a 5 MiB blank file. Change the file size as necessary.
Type "mkdosfs efi.img" to create a FAT filesystem on the efi.img file.
Type "mount -o loop efi.img /mnt" as root. Change the mount point as desired; but if you do, change it in subsequent commands, too.
Type "cp -R /boot/efi/* /mnt" as root.
Type "umount /mnt" as root.
Type 'mkisofs -U -V "testboot" -volset "testboot x86_64" -J -joliet-long -r -v -T -o ../testboot-cd.iso -eltorito-alt-boot --efi-boot efi.img -no-emul-boot ./'. This should create a bootable CD-R image file, testboot-cd.iso, in the parent directory.
Burn ../testboot-cd.iso to a CD-RW and try it.


With any luck, this disc should boot your Linux installation directly; however, this assumes that the boot loader configuration in your ESP is already correct. If it's not, you'll need to make changes to the ESP, copy the files back into the image file, create a new ISO image file, and burn it again. That's a tedious way to test changes, which is why I suggested trying a USB flash drive -- it's much easier to test changes with it.

Don3
29th February 2012, 07:32 PM
Originally posted by srs5694

Have you tried flashing a new firmware image? Even if it's the same version you're running now, that might improve matters if your firmware has become damaged in some way.


Good thought. I tried that when I first had problems getting EFI to work, and then noticed that I couldn't revert to BIOS mode, before I even started this thread. At that time I upgraded from the BIOS version I had been using for most of the last 4 years to the latest available for that board, from 2009. Just now I re-installed that latest version, but unfortunately it didn't help.




Going a bit further, if the board has a socketed EEPROM chip, you could replace it with a new one in case it's become physically damaged.


I don't see any socketed ICs on the board, other than the CPU, of course.




The failure to launch the shell from rEFIt suggests a very serious error. I don't recognize the error message you got, but it makes me think your firmware has become corrupted. That's a very tentative conclusion, though.


Even though re-flashing it didn't help, I agree it's still entirely possible that BIOS flash, or whatever RAM it uses, or its NV storage area could be faulty. It would be nice if there was a way to test any/all of those.




I've posted a new version of my rEFIt boot CD. There's now a download link at http://www.rodsbooks.com/efi-bootloaders/refit.html. It differs in a couple of ways from the version you've got, one of which might conceivably produce better boot options, although I'm not very hopeful about that.


Thanks for the new version. This one works basically the same as the "cd2" version, except that there's only 1 big icon in the top row, which just seems to re-launch the rEFIt menu. Same assert error trying to launch the shell.




Have you tried booting a USB flash drive in EFI mode? In theory, you can set one up with GPT and an ESP and toss boot loaders on it. If it works, it'd be a little easier to experiment with than a bootable CD.


I did try it once or twice, not only because I thought it should be a lot easier and faster to try experiments, but also because it's probably a more appealing long-term solution if I can't get normal booting from firmware to work. It's faster of course, hopefully more reliable (sometimes it takes a couple tries to get the firmware to see a CD), and I could just leave a small flash drive plugged into one of the back-panel USB ports, rather than having to fiddle with CDs. My earlier experiments didn't work -- well, I did manage to elicit some other error besides the good ol' "No bootable device" -- but I wasn't sure exactly what the firmware would be looking for on a USB drive (and there's at least one option about handling of USB storage, which also no longer sticks), so I decided not to introduce yet another variable into this mess until I understood what was going on. I'm certainly willing to try again though. I assume it should work (with sane firmware) to simply put a GPT with a single FAT32 ESP directly on the USB drive...?

Thanks very much for the info about creating bootable CDs! I will give this a try later. Which version of mkisofs are you using? I don't see the "-efi-boot" option in the man page on Fedora 14, but it's there in the F16 installation -- yet both executables claim to be the same version: genisoimage 1.1.11 (Linux). OTOH the RPM packages do have different suffixes...

---------- Post added at 12:32 PM ---------- Previous post was at 12:26 PM ----------

Oh, another question: Do we know whether either the redhat or fedora .efi bootloaders are supposed to have config files with them? It seems the GRUB Legacy and GRUB2 installers don't create any. So far it's been kind of an academic question for me since I don't seem to be getting that far, but if I try again with a USB drive, it would be good to know...

srs5694
1st March 2012, 01:20 AM
Good thought. I tried that when I first had problems getting EFI to work, and then noticed that I couldn't revert to BIOS mode, before I even started this thread. At that time I upgraded from the BIOS version I had been using for most of the last 4 years to the latest available for that board, from 2009. Just now I re-installed that latest version, but unfortunately it didn't help.

It's conceivable (albeit unlikely) that you're seeing an unfixed bug in the 2009 version of the firmware that's not present in earlier versions. Thus, it might be worth downgrading a version or two.


I don't see any socketed ICs on the board, other than the CPU, of course.

Too bad. You might check the manual to see if it has a diagram that identifies where the EEPROM chip is located. You could then look there specifically, just in case you overlooked something earlier.


Even though re-flashing it didn't help, I agree it's still entirely possible that BIOS flash, or whatever RAM it uses, or its NV storage area could be faulty. It would be nice if there was a way to test any/all of those.

I don't know if there's a way to test those.


I assume it should work (with sane firmware) to simply put a GPT with a single FAT32 ESP directly on the USB drive...?

Yes, that's the idea -- just copy over your existing ESP's files to a new ESP on the USB flash drive. You might need to tell the board to boot from the USB flash drive or use the rEFIt disc to get a rEFIt boot menu that includes those files, at least initially.


Thanks very much for the info about creating bootable CDs! I will give this a try later. Which version of mkisofs are you using? I don't see the "-efi-boot" option in the man page on Fedora 14, but it's there in the F16 installation -- yet both executables claim to be the same version: genisoimage 1.1.11 (Linux). OTOH the RPM packages do have different suffixes...

I used mkisofs in Fedora 16. I also tried the version in Gentoo, but it lacks the --efi-boot option, too. I guess it must be a fairly new option....


Oh, another question: Do we know whether either the redhat or fedora .efi bootloaders are supposed to have config files with them? It seems the GRUB Legacy and GRUB2 installers don't create any. So far it's been kind of an academic question for me since I don't seem to be getting that far, but if I try again with a USB drive, it would be good to know...

AFAIK, GRUB Legacy requires a configuration file with the same name as the boot loader file but with a .conf extension in the same directory as the boot loader file. GRUB 2's requirements depend on how it was compiled, and I don't know how Fedora's developers have done that. (I've never tried Fedora's GRUB 2 for EFI.) See this page (https://help.ubuntu.com/community/UEFIBooting) for information on compiling GRUB 2 for (U)EFI, if you care to dig into doing it yourself at a low level. (The page is hosted on an Ubuntu site, but its contents actually originated on the GRUB 2 site and apply to any distribution. For some inexplicable reason, the GRUB 2 Web developers chose to remove this vital information, and the Ubuntu people took it over.)

I have one other idea, but it depends on your being able to boot a USB flash drive in BIOS mode: You could install your boot loader (GRUB Legacy or GRUB 2) to boot in BIOS mode on a USB flash drive. This should be relatively easy to test -- just stick the flash drive in and install GRUB to it as if it were a hard disk. If done right, GRUB on the flash drive would look for GRUB configuration files in /boot on your hard disk. (If you use GPT on the flash drive, you might need a BIOS Boot Partition. Note also that Intel's firmware likes to see an MBR partition with its boot flag set when booting in BIOS mode, so you should probably set a boot flag on an MBR partition with fdisk. If you use GPT, this will have to be the 0xEE protective partition, but if you use MBR, you may need to create a "junk" partition for this purpose.) Alternatively, you could create /boot on the USB flash drive. This would slow the boot process a bit, but probably not too much.

---------- Post added at 07:20 PM ---------- Previous post was at 02:04 PM ----------

I've just reviewed this thread (but I skimmed large parts of it, so I may have missed something). I noticed that one commonality to your tests is that you've always used GPT disks. It's possible that this is at least part of the problem -- perhaps the firmware is seeing the GPT disk and refusing to set its BIOS-mode boot option as a result of that. Therefore, if you've got a spare hard disk, I recommend the following:


Install the spare disk and boot an emergency disc (Parted Magic, System Rescue CD, or a Linux installer in "live CD" mode).
Launch parted or GParted and create a fresh MBR partition table.
Create partitions for a Fedora installation.
Shut down and reboot the Fedora installer in BIOS mode. Verify you're in BIOS mode by examining the dmesg output for "EFI" strings, as described in one of my earliest posts in this thread.
Install Fedora in BIOS mode.
Reboot and hope it works.


If this latest hypothesis of mine is correct (and I'm far from certain that it is), you should boot up OK. If not, you can try again to disable the EFI boot option in the firmware's setup utility. This hypothesis doesn't explain why the board refuses to boot from what appear to be valid EFI boot files, but it could still explain at least part of the problem, and it at least suggests a possible solution.

Don3
2nd March 2012, 04:29 AM
Originally posted by srs5694

It's conceivable (albeit unlikely) that you're seeing an unfixed bug in the 2009 version of the firmware that's not present in earlier versions. Thus, it might be worth downgrading a version or two.


I had thought several times over the last couple weeks about trying this, but since I was on an older BIOS version when I first encountered all these issues, it hadn't been a real high priority. Last night I tried flashing the version I had been using until recently, 0517, but flashing failed. An error code was displayed on the screen, but it didn't stay there long enough to write it down. Hmm. I verified my BIOS upgrade CD contents matched the original ISO image from Intel. Then I went back to an even older version, 0305, which I had used for a while when I first got the board. Flashing failed on that one too. Finally I put the latest one, 0572, back on the CD and went through the flashing procedure again. This time it succeeded. So I'm guessing something is preventing down-grading the BIOS. There is a "BIOS recovery" procedure (chrismurphy reminded me of this earlier) which may allow downgrades, but when I tried it using a USB flash drive back then it failed to boot the drive, so I just left it. I suppose I could have another shot at that.



I have one other idea, but it depends on your being able to boot a USB flash drive in BIOS mode: You could install your boot loader (GRUB Legacy or GRUB 2) to boot in BIOS mode on a USB flash drive. This should be relatively easy to test -- just stick the flash drive in and install GRUB to it as if it were a hard disk. If done right, GRUB on the flash drive would look for GRUB configuration files in /boot on your hard disk.

This seems like a good idea too... The installation (grub2-install) on the USB drive seemed to work, after some fiddling. I had to allow enough room between the MBR and the first partition for the "embedded image" (core.img, IIRC), and I had to set the bootable flag on the one and only partition I created on it, even though there was nothing in it. Although the installer seemed happy, the BIOS was less than impressed. However, the failure message was different this time:


This is not a bootable disk. Please insert a bootable floppy and
press any key to try again...




I've just reviewed this thread

BTW, I would like to thank you and chrismurphy for spending so much time on this..!



I noticed that one commonality to your tests is that you've always used GPT disks. It's possible that this is at least part of the problem -- perhaps the firmware is seeing the GPT disk and refusing to set its BIOS-mode boot option as a result of that. Therefore, if you've got a spare hard disk, I recommend...

I think you're right about the thread. However, back before I started the thread, but after the EFI boot option became "stuck on", I had tried re-connecting the drive that had been the boot drive during the last couple years, which has an MBR partition table - and that no longer worked. And when I've disconnected all the discs, I've still been unable to turn off EFI boot. Although I was annoyed that I couldn't even go back to my old installation, I like the GPT disk layout much better than MBR (no CHS nonsense, for starters), and from what I've read UEFI should displace MBR (Real Soon Now), so I wasn't so disappointed to jump into those -- eager, in the case of GPT...

In any case, today I tried wiping my new SSD, setting up an MBR partiioning scheme, and installing in BIOS mode as you suggested, and to my surprise, it does boot!!! I did it twice, just to make sure. On the second try, I hit F2 and looked at the boot options -- "EFI boot" is still enabled, yet it is booting an OS from this MBR/BIOS installation. Weeeeird. And incredible that an Intel EFI system can't seem to boot from GPT-formatted discs.

So thanks for that!!! Now I need to decide how to go forward from here. I would still like the other disks that will be installed in the system to use GPT if at all possible. From what I can see on Fedora 14, Linux doesn't seem to have any issue with mixing GPT and MBR drives.

srs5694
2nd March 2012, 04:33 PM
I'm glad you've finally found a possible way forward! I was beginning to think I'd have to advise you to replace the motherboard, although I detest throwing away hardware if there's any chance of salvaging it.

Anyhow, the "EFI boot" option in Intel's boards only enables EFI support; it doesn't disable BIOS mode. That is, with the option enabled, either method should work. Thus, it's no real shock that you were able to boot in a BIOS way with the EFI option enabled.

In principle, you should be able to mix an MBR boot disk with a GPT data disk. In fact, I booted my MythTV box (with an Intel motherboard) for some time that way, and it worked fine. (Of course, my firmware wasn't doing weird things the way yours is, so this isn't any guarantee that you'll have success.)

Good luck moving forward!