Booting with EFI
Jul. 14th, 2011 12:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59One of the ways in which EFI is *actually* better than BIOS is its native support for multiple boot choices. All EFI systems should have an EFI system partition which holds the OS bootloaders. Collisions are avoided by operating system vendors registering a unique name here, so there's no risk that Microsoft will overwrite the Fedora bootloader or whatever. After installing the bootloader the OS installer simply sets an NVRAM variable pointing at it, along with a descriptive name and (if they want) sets the default boot variable to point at that. The firmware will then typically provide some mechanism to override that default by providing a menu of all the configured variables.
This obviously doesn't work so well for removable media, where otherwise you'd have an awkward chicken and egg problem or have to force people to drop to a shell and run the bootloader themselves. This is handled by looking for EFI/boot/boot(architecture).efi, where architecture depends on the system type - examples include bootia32.efi, bootia64.efi and bootx64.efi. Since vendors have complete control over their media, there's still no risk of collisions.
Why do we care about collisions? The main reason this is helpful is that it means that there's no single part of the disk that every OS wants to control. If you install Windows it'll write stuff in the MBR and set the Windows partition as active. If you install Linux you'll either have to install grub in the MBR or set the Linux partition as active. Multiple Linux installations, more problems. It's very, very annoying to handle the multiple OS case with traditional BIOS.
This was all fine until UEFI 2.3 added section 3.4.1.2 of the spec, which specifies that in the absence of any configured boot variables it is permitted for the firmware to treat the EFI system partition in the same way as removable media - that is, it'll boot EFI/boot/bootx64.efi or whatever. And, if you install Windows via EFI, it'll install an EFI/boot/bootx64.efi fallback bootloader as well as putting one in EFI/microsoft.
Or, in other words, if your system fails to implement the boot variable section of the specification, Windows will still boot correctly.
As we've seen many times in the past, the only thing many hardware vendors do is check that Windows boots correctly. Which means that it's utterly unsurprising to discover that there are some systems that appear to ignore EFI boot variables and just look for the fallback bootloader instead. The fallback bootloader that has no namespacing, guaranteeing collisions if multiple operating systems are installed on the same system.
It could be worse. If there's already a bootloader there, Windows won't overwrite it. So things are marginally better than in the MBR days. But the Windows bootloader won't boot Linux, so if Windows gets there first we still have problems. The only solution I've come up with so far is to have a stub bootloader that is intelligent enough to scan the EFI system partition for any other bootloaders and present them as a menu, and for every Linux install to just blindly overwrite bootx64.efi if it already exists. Spec-compliant firmware should always ignore this and run whatever's in the boot variables instead.
This is all clearly less than optimal. Welcome to EFI.
This obviously doesn't work so well for removable media, where otherwise you'd have an awkward chicken and egg problem or have to force people to drop to a shell and run the bootloader themselves. This is handled by looking for EFI/boot/boot(architecture).efi, where architecture depends on the system type - examples include bootia32.efi, bootia64.efi and bootx64.efi. Since vendors have complete control over their media, there's still no risk of collisions.
Why do we care about collisions? The main reason this is helpful is that it means that there's no single part of the disk that every OS wants to control. If you install Windows it'll write stuff in the MBR and set the Windows partition as active. If you install Linux you'll either have to install grub in the MBR or set the Linux partition as active. Multiple Linux installations, more problems. It's very, very annoying to handle the multiple OS case with traditional BIOS.
This was all fine until UEFI 2.3 added section 3.4.1.2 of the spec, which specifies that in the absence of any configured boot variables it is permitted for the firmware to treat the EFI system partition in the same way as removable media - that is, it'll boot EFI/boot/bootx64.efi or whatever. And, if you install Windows via EFI, it'll install an EFI/boot/bootx64.efi fallback bootloader as well as putting one in EFI/microsoft.
Or, in other words, if your system fails to implement the boot variable section of the specification, Windows will still boot correctly.
As we've seen many times in the past, the only thing many hardware vendors do is check that Windows boots correctly. Which means that it's utterly unsurprising to discover that there are some systems that appear to ignore EFI boot variables and just look for the fallback bootloader instead. The fallback bootloader that has no namespacing, guaranteeing collisions if multiple operating systems are installed on the same system.
It could be worse. If there's already a bootloader there, Windows won't overwrite it. So things are marginally better than in the MBR days. But the Windows bootloader won't boot Linux, so if Windows gets there first we still have problems. The only solution I've come up with so far is to have a stub bootloader that is intelligent enough to scan the EFI system partition for any other bootloaders and present them as a menu, and for every Linux install to just blindly overwrite bootx64.efi if it already exists. Spec-compliant firmware should always ignore this and run whatever's in the boot variables instead.
This is all clearly less than optimal. Welcome to EFI.
Checkout grub2_uefi.sh
Date: 2011-07-15 03:09 pm (UTC)I dual-boot Windows 7 Professional x64 and Archlinux x86_64 using Tianocore DUET UEFI firmware. Details about DUET and other random UEFI stuff are at https://gitorious.org/tianocore_uefi_duet_builds/pages/Home . https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB#5.+Add+Windows+Chainload+commands might give an idea as to how to chainload Windows bootmgfw.efi app from grub2's grub.efi . I don't know whether Fedora's grub-legacy efi or elilo or the WIP efilinux (http://git.kernel.org/?p=boot/efilinux/efilinux.git;a=summary) support such functionality.
So this means you are getting closer to installing Linux on Xbox360?
Date: 2011-07-18 08:44 am (UTC)no subject
Date: 2011-07-20 02:08 pm (UTC)So it's rude and obnoxious in exactly the same way Windows used to be accused of for always trampling the MBR on install, then?
no subject
Date: 2011-07-20 02:10 pm (UTC)no subject
Date: 2011-09-08 02:39 pm (UTC)I'm a firmware engineer. To my understanding, the EFI firmware should be able to boot from the loader specified by the variable set by OS (the variable is called "Boot Options" in EFI spec). According to our test (unfortunately, most test are windows related..), only windows boot loader itself will try to re-set a new variable if the original one set by windows is gone. But for Linux, it will not reset the variable. That means, Linux may need some procedure to recover the boot variable if it is gone. I think there are some possible solutions like: to boot to UFD and have some tool to recover the bootoption. To overwrite the loader under EFI\Boot\Bootxxxx.efi is not a good idea (although Windows is doing this...), it only causes more conflicts.
Another possible way is to include the file path for the boot loader for common OSes into the computer, but there is always new OS, and perhaps new paths. I am not sure if the OSes rely on EFI firmware to add support for them.
I am also curious about how different computer vendors handle the EFI loader. For example, the EFI firmware boots to the bootoption created by OS or not? How it presents the bootoptions build by OS, and etc. It will be perfect if you can let me know what computer (brand) you are using to install the EFI aware OS, and if you can also let me know the EFI firmware vendor, it will be perfect.
Tell the truth, I think many (most) vendors are still not quite familiar with the EFI boot, and don't really have a standard for building and booting to the bootoptions. Most tests are done for Windows only.