[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

UEFI is here (on Sandy Bridge) and the boot order is wrong

UEFI is here for real, and (at least as F14) we're not really ready
for it.  (You can buy >2TB disks, and AFAICT basically all Cougar
Point motherboards support UEFI.)

I have a new DH67GD board (one of Intel's Sandy Bridge / Cougar Point
boards), and in a fit of masochism I decided to install Fedora 14 in
EFI mode.  I had two problems, both related to anaconda.  I'll deal
with the more straightforward issue first.

When installing to an EFI system (i.e. disk is GPT and the installer
was booted in EFI mode), anaconda installs grub to
/boot/efi/EFI/redhat/grub.efi and sets up an entry in efibootmgr to
point to it.  This interacts rather badly with my motherboard.  As far
as I can tell (note: this is deduced from limited experimentation),
when UEFI is enabled in my firmware, the actual boot order is:

1. Boot from *devices* in the order specified in firmware config.
(This has nothing at all to do with efibootmgr AFAICT.)  I'll get to
what "booting from a device" means below.
2. Boot from *disabled* devices in some order (I haven't tried to
figure out what order).
3. Boot from efibootmgr entries (presumably in order specified in efibootmgr).

Asking for the boot menu on startup overrides this order.

When booting from a device, my firmware seems to behave quite
differently depending on whether the device is removable.  For a hard
disk, the firmware will try to load /EFI/BOOT/BOOTX64.efi.  If that
fails, the firmware will try to boot from the MBR.  For a CD-ROM or
USB stick, the firmware will consider EFI boot and old-style BIOS boot
to be two different devices (and they will show separately in the boot
menu if the boot menu is shown).

The problem is that anaconda does not create /EFI/BOOT/BOOTX64.efi.
This means that EFI boot *from the hard disk* fails and the firmware
will fall back to all kinds of absurd options.  If there's an MBR boot
record (and there is one on my disk that doesn't actually boot
anything), then that gets loaded and the boot fails.  If there's a
CD-ROM in the drive that's bootable, the firmware will boot from it
*even if "boot from CD-ROM" is explicitly disabled*.  Finally, if none
of those appear bootable, then the firmware will fall back to the
efibootmgr-recorded option and boot successfully.  I've fixed it
locally by copying grub.efi to /EFI/BOOT/BOOTX64, which means that my
system reliably boots from the EFI grub on my disk.  Should anaconda
create that file?


Second issue: If I booted the installer in BIOS (i.e. not EFI) mode or
if my hard disk is not GPT, how do I install in EFI mode?  Clearly EFI
should not be the default if I booted in BIOS mode, but what if I want
to override that (or change the disk over to GPT)?  In my case I
booted the installer in BIOS mode because my firmware interacted
poorly with F14's EFI live CD.  (F15 TC1 worked, but the installer was
so broken that I just gave up.)

I'd be happy to do some limited experimentation here to help out.
Unfortunately, this is a system I use with only one hard disk, and I
testing in KVM isn't helpful.  I don't really want to do a bunch of
fresh installs if I can avoid it.  I would, however, be happy to
experiment with efibootmgr, weird files in /boot/efi, and other such
lightweight experiments.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]