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. Thanks, Andy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
