4

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:

enter image description here

GPT containing ESP:

enter image description here

Figures found on page 117,118 of the specification

  • See this – Moab Sep 22 '15 at 21:35
  • 1
    In most ESPs, the boot manager entries stored in NVRAM each identify a specific partition and a filename of a file on that partition. In practice, the firmware doesn't really care whether the partition is flagged as an EFI System Partition (ESP). The firmware also doesn't actively scan for ESPs; it just relies on the NVRAM entries to have appropriate pointers. Some third-party tools, like rEFIt and my rEFInd (which is forked from rEFIt), do actively scan for boot loaders, but they don't really care about ESP status; they just scan all readable filesystems for boot loaders in common places. – Rod Smith Sep 23 '15 at 21:03
  • Ok makes sense, and I def trust your opinion :) ...so basically the NVRAM global vars (at least the ones that identify partitions) are very similar/same as MBR "flagged" active partitions then right? – Jordan Davis Sep 23 '15 at 21:51
  • If I'm not wrong, UEFI implementations may themselves try to detect an ESP on a GPT disk if you don't use an explicit boot entry to boot (but you rather select a bare block device, e.g. harddrive as the boot point). – bool3max Jan 21 at 23:17
1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.