On 02/16/2011 09:34 AM, Andrew Lutomirski wrote:
> 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).
This is a bit weird; none of my Intel machines put anything before the EFI
boot variables by default, and doing so is pretty much just wrong. Hopefully
this is configurable, because there's basically nothing we can do about your
firmware getting the boot order wrong. In theory we could set the disk up
as if it's a removable device, which sounds like it might fix this issue,
but it creates more and wildly violates the standard.
In short, look for config options to try to get this right, because there's
not much we can really do about it.
> 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).
Yeah, firmwares seem to have all kinds of crazy fallback orderings
and preferences for how to fall back depending on device types. There's
a lot of work on the hardware side that still needs to get done sanitizing
this stuff.
> 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?
According to the standard we *can't* create that file on the installed system.
It's okay to do on the (removable) install media, but not something that's
okay to do on the installed system, because the EFI System Partition is a
shared resource between us and other operating systems. When we're writing
the bootloader to it, the standard mandates that we stick it in our own
subdirectory - i.e. /EFI/REDHAT/.
> --------------------
>
> 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.)
So, if your machine will boot off of an MBR-partitioned system (which it
probably will even though the standard doesn't mandate it), then basically:
1) create an EFI system partition (this unfortunately means you need to
leave some space available.) That is, make a partition and format it
with mkfs.vfat .
2) mount it on /tmp/efi/
3) rsync -avSHP /boot/efi/ /tmp/efi/
4) umount /tmp/efi and remount it on /boot/efi
5) add it to fstab
6) make sure the symlink at /etc/grub.conf points to /boot/efi/efi/redhat/grub.conf
7) make sure the grub.conf at that location will work
8) reboot and manually tell the firmware to boot /boot/efi/efi/redhat/grub.efi
9) use efibootmgr to add grub.efi to the boot order
10) use the output of efibootmgr -v to modify grub.conf - look at the code in
getEfiProductPath() in pyanaconda/booty/bootloaderInfo.py for how to do
this.
That should result in the grub.efi file being in the boot order; obviously
if it's not correctly honoring the boot order that won't help much.
--
Peter
The Shuttle is now going five times the sound of speed.
-- Dan Rather, first landing of Columbia
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
