Some things about booting with UEFI that are different from MBR booting

December 11, 2017

If you don't dig into it, a PC that boots with UEFI seems basically the same as one that uses BIOS MBR booting, even if you have multiple OSes installed (for example, Linux and Windows 10). In either case, with Linux you boot into a GRUB boot menu with entries for Linux kernels and also Windows, and you can go on to boot either. However, under the hood this is an illusion and there are some important differences, as I learned in a recent UEFI adventure.

In BIOS MBR booting, there's a single bootloader per disk (loaded from the MBR). You only ever boot this bootloader; if it goes on to boot an entire alternate OS, it's often doing tricky magic to make them think they've been booted from the MBR. If you call up the BIOS boot menu, what it offers you is a choice of which disk to load the MBR bootloader from. When you install a bootloader on a disk, for example when your Linux distribution's installer sets up GRUB, it overwrites any previous bootloader present; in order to keep booting other things, they have to be in the configuration for your new bootloader. Since there's only one bootloader on a disk, loss or corruption of this bootloader is fatal for booting from the disk, even if you have an alternate OS there.

In UEFI booting, there isn't a single bootloader per disk the way there is with MBR booting. Instead, the UEFI firmware itself may have multiple boot entries; if you installed multiple OSes, it almost certainly does (with one entry per OS). The UEFI boot manager tries these boot entries in whatever order it's been set to, passing control to the first one that successfully loads. This UEFI bootloader can then do whatever it wants to; in GRUB's case, it will normally display its boot menu and then go on to boot the default entry. If you call up the UEFI firmware boot menu, what you see is these UEFI boot entries, probably augmented with any additional disks that have an EFI system partition with an EFI/BOOT/BOOTX64.EFI file on them (this is the default UEFI bootloader name for 64-bit x86 systems). This may reveal UEFI boot entries that you didn't realize were (still) there, such as a UEFI Windows boot entry or a lingering Linux one.

(If you have multiple fixed disks with EFI system partitions, I believe that you can have UEFI boot entries that refer to different disks. So in a mirrored system disk setup, in theory you could have an UEFI boot entry for the EFI system partition on each system disk.)

The possibility of multiple UEFI boot entries means that your machine can boot an alternate OS that has a UEFI boot entry even if your normal primary (UEFI) bootloader is damaged, for example if it has a corrupted or missing configuration file. Under some situations your machine may transparently fall back to such an additional UEFI boot entry, which can be pretty puzzling if you're used to the normal BIOS MBR situation where either your normal bootloader comes up or the BIOS reports 'cannot boot from this disk'. It's also possible to have two UEFI boot entries for the same OS, one of which works and one of which doesn't (or, for a non-hypothetical example, one which only works when Secure Boot is off because it uses an an unsigned UEFI bootloader).

A UEFI bootloader that wants to boot an alternate OS has more options than a BIOS MBR bootloader does. Often the simplest way is to use UEFI firmware services to load the UEFI bootloader for the other OS and transfer control to it. For instance, in GRUB:

chainloader /EFI/Microsoft/Boot/bootmgfw.efi

This is starting exactly the same Windows UEFI bootloader that my Windows UEFI boot entry uses. I'm not sure that Windows notices any difference between being booted directly from its UEFI boot entry and being chainloaded this way. However, such chainloading doesn't require that there still be a UEFI boot entry for the alternate OS, just that the UEFI bootloader .EFI file still be present and working. Similarly, you can have UEFI boot entries for alternate OSes that aren't present in your GRUB menu; the two systems are normally decoupled from each other.

(You could have a UEFI bootloader that read all the UEFI boot entries and added menu entries for any additional ones, but I don't believe that GRUB does this. You could also have a grub.cfg menu builder that used efibootmgr to automatically discover such additional entries.)

A UEFI bootloader is not obliged to have a boot menu or support booting alternate OSes (or even alternate installs of its own OS), because in theory that's what additional UEFI boot entries are for. The Windows 10 UEFI bootloader normally boots straight into Windows, for example. Linux UEFI bootloaders will usually have an option for a boot menu, though, because in Linux you typically want to have more than one kernel as an option (if only so you can fall back to the previous kernel if a new one has problems).

(In theory you could probably implement multiple kernels as multiple UEFI boot entries, but this gets complicated, there's only so many of them (I believe five), and apparently UEFI firmware is often happier if you change its NVRAM variables as little as possible.)

Sidebar: UEFI multi-OS food fights

In the BIOS MBR world, installing multiple OSes could result in each new OS overwriting the MBR bootloader with its own bootloader, possibly locking you out of the other OSes. In the UEFI world there's no single bootloader any more, so you can't directly get this sort of food fight; each OS should normally only modify its own UEFI boot entry and not touch other ones (although if you run out of empty ones, who knows what will happen). However, UEFI does have the idea of a user-modifiable order for these boot entries, so an OS (new or existing) can decide that its UEFI boot entry should of course go at the front of that list, so it's the default thing that gets booted by the machine.

I suspect that newly installed OSes will almost always try to put themselves in as the first and thus default UEFI boot entry. Existing OSes may or may not do this routinely, but I wouldn't be surprised if they definitely did it should you tell them to check for boot problems and repair anything they find. Probably this is a feature.

Written on 11 December 2017.
« Let's Encrypt and a TLS monoculture
Some notes on systemd-resolved, the systemd DNS resolver »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Dec 11 22:22:18 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.