UEFI detection (ESPs)

bootbootloaderbootmgrgptuefi

Does the UEFI boot manager detect the ESPs inside the GPTs on every storage device, based on the global-scope variables (boot-configuration) stored in NVRAM?

Reading the UEFI booting from Wikipedia:

Unlike BIOS, UEFI does not rely on a boot sector, defining instead a
boot manager as part of the UEFI specification. When a computer is
powered on, the boot manager checks the boot configuration and, based
on its settings, loads and executes the specified operating system
loader or operating system kernel. The boot configuration is a set of
global-scope variables stored in NVRAM, including the boot variables
that indicate the paths to operating system loaders or kernels, which
as a component class of UEFI applications are stored as files on the
firmware-accessible EFI System partition (ESP).

UEFI relies on a "boot manager" which check the configuration (set of global-scope variables stored in NVRAM), this configuration includes boot variables that indicate paths to OS loaders/kernels, which are components of "UEFI applications" (which are stored as files on an ESP – aka GPT Partition(1) using FAT(12|16|32) File Format)

Looking at the Boot Manager section of the UEFI specification:

GPT Layout:

GPT containing ESP:

Figures found on page 117,118 of the specification

Best Answer

The UEFI boot managers reads its configuration from EFI variables (that are stored in NVRAM). Depending on the configured entries and the configured boot boot order it might very well search for a ESP on each storage device.

For example, if you have - say - 2 storage devices and for each a generic entry like

PciRoot(0x0)/Pci(0x5,0x0)    # or
PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)

and they are both referenced in the boot order then the UEFI boot manager probes them both for ESPs.

Also, the UEFI specification doesn't forbid the firmware to auto-add some generic entries on each boot for each newly detected storage device. Thus, depending on your system you might end up with it auto-detecting an ESP on any detected storage device, by default.

The UEFI specification also allows the firmware to discover an ESP that doesn't use the EFI system parition GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B). Instead it might just probe for a GPT partition with a FAT filesystem and the expected file under EFI/BOOT (e.g. BOOTX64.EFI on a x86 64 bit system):

UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in Section 13.3.1.1. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes (see 5.3.3) which will exclude the partition as a potential ESP.

(UEFI specification version 2.7 errata A, Section 13.3.3 Number and Location of System Partitions, page 516)

For example, the Supermicro and Qemu UEFI firmware do this.

Related Solutions

Linux – How many EFI System Partitions (ESP) can a computer have

You're operating under the misapprehension that PKs are tied to ESPs; they aren't. The Secure Boot cryptographic features require that individual boot loader files be signed, but those files are stored on ordinary FAT filesystems that are themselves not signed, encrypted, or otherwise cryptographically interesting. A signed boot loader file can be moved from one partition to another and continue to work just fine, at least from a Secure Boot perspective. (Moving such a file may cause it to fail because it's been separated from critical configuration files or the like, of course, but that's another matter.)

To more directly answer the question, the EFI specification imposes no limit on the number of ESPs that may be present on a computer or on a hard disk; you could have dozens of them if you wanted to, and that would be fine from the EFI's perspective. Unfortunately, Microsoft is not so flexible; Windows officially supports just one ESP per disk (maybe per computer; I'm a bit foggy on that detail). I don't know about Windows 8, but the Windows 7 installer will flake out if it sees more than one ESP on a disk; the installation will proceed part of the way and then fail. (At least, that's what it's done in my tests.) That said, if you create a second ESP after installing Windows, Windows will continue to boot and operate correctly, at least as far as I've seen. (I can't promise that it won't misbehave if you use some particular feature, though.)

Overall, then, in a multi-boot environment, I recommend restricting yourself to one ESP. I also recommend making it rather large -- 550MiB is my usual recommendation, for assorted technical reasons having to do with rare bugs and FAT sizes. That said, if you've got an existing installation with a smaller ESP, it's probably fine to just stick with it. In either case, Linux and Windows can share a single ESP just fine. I do, however, recommend backing it up early and often -- definitely back it up before installing a new OS. Because the ESP holds your boot loaders, an accidental erasure of it will render your computer unbootable.

Windows – How are the initial boot files found in UEFI

On UEFI System Partition paths begin with \EFI !

For example:

Z:\EFI\Boot\bootx64.efi

Z:\EFI\Microsoft\Boot\bootmgfw.efi

Z:\EFI\ubuntu\grubx64.efi

"\EFI\Boot" folder/directory stores the default fallback boot loader.

\EFI\'Company' - are also reserved names.

'Company' folder can have any structure (sub, sub-sub folders). The corresponding boot entry has the correct path to boot loader file, e.g. "\EFI\Microsoft\Boot\bootmgfw.efi"

Best Answer

Related Solutions

Linux – How many EFI System Partitions (ESP) can a computer have

Windows – How are the initial boot files found in UEFI

Related Question