How UEFI Handles Multiple Boot Entries in the ESP

This article explains how the Unified Extensible Firmware Interface (UEFI) manages multi-boot environments through the EFI System Partition (ESP). By utilizing a standardized directory structure alongside firmware-level Non-Volatile RAM (NVRAM) variables, UEFI allows multiple operating systems to coexist on a single drive without overwriting each other's bootloaders. Readers will learn the mechanics of the ESP file structure, how the firmware locates and executes boot files, how boot priority is maintained, and how the system handles bootloader fallbacks.

The Structure of the EFI System Partition

The EFI System Partition is typically formatted with the FAT32 file system, ensuring universal readability across different operating systems and the UEFI firmware. Within this partition, UEFI enforces a specific directory hierarchy under a root directory named EFI.

Rather than sharing a single boot sector—as legacy Master Boot Record (MBR) systems did—UEFI isolates each operating system into its own dedicated vendor directory:

ESP/
└── EFI/
    ├── Microsoft/
    │   └── Boot/
    │       └── bootmgfw.efi
    ├── ubuntu/
    │   ├── grubx64.efi
    │   └── shimx64.efi
    ├── fedora/
    │   └── grubx64.efi
    └── BOOT/
        └── BOOTX64.EFI

Because each operating system installs its executable files (.efi binaries) and configuration data into separate subdirectories, installing a new OS does not destroy or overwrite existing bootloaders.

NVRAM Variables: Bridging Hardware and Files

The physical .efi files on disk are only one half of the UEFI boot mechanism. The firmware relies on NVRAM (Non-Volatile Random-Access Memory) variables stored directly on the motherboard to recognize and locate these files.

When an operating system is installed, its installer registers a new entry in the motherboard’s NVRAM. These variables are defined under the UEFI specification:

  • Boot#### Variables: Each registered boot option is assigned a hexadecimal identifier (such as Boot0001, Boot0002). Each variable contains a human-readable title (e.g., "Windows Boot Manager" or "ubuntu"), a pointer to the specific disk partition via its Globally Unique Identifier (GUID), and the exact file path to the target .efi binary.
  • BootOrder Variable: This critical variable defines the execution sequence as an array of the Boot#### identifiers (e.g., Boot0002, Boot0001, Boot0000). It instructs the firmware which boot entry to attempt first, second, and so on.
  • BootNext Variable: An optional variable that specifies a one-time boot override for the next reboot, returning to the normal BootOrder afterward.

The Boot Sequence and Resolution

During system startup, the UEFI firmware initializes hardware and executes the boot sequence through the following steps:

  1. Reading NVRAM: The firmware inspects the BootOrder list to identify the highest-priority target.
  2. Locating the Partition: It references the GUID defined within that entry's Boot#### variable to locate the correct ESP on the storage drive.
  3. Loading the Binary: The firmware reads the designated .efi file into memory (e.g., \EFI\ubuntu\shimx64.efi) and transfers execution to it.
  4. Handling Failures: If the primary entry's binary cannot be found, is corrupted, or fails Secure Boot signature verification, the firmware aborts that execution and falls back to the next identifier listed in BootOrder.

The Default Fallback Path

If the motherboard’s NVRAM is cleared, reset, or corrupted, the firmware loses its registered pointers. To prevent an unbootable state, the UEFI specification defines a standardized fallback path:

\EFI\BOOT\BOOTX64.EFI (on 64-bit x86 systems)

If no NVRAM entries exist or all registered paths fail, the firmware scans every accessible FAT32 partition for this exact directory and file. Removable media, such as USB installation drives, rely almost exclusively on this fallback path because they cannot pre-register NVRAM entries on target systems.

Boot Entry Management Tools

Operating systems interact with UEFI NVRAM through firmware runtime services. This allows software to safely modify the boot order, create new entries, or delete deprecated paths without entering the motherboard's setup menu:

  • Linux: Uses the efibootmgr utility to read, create, and reorder boot variables in NVRAM via the efivarfs kernel interface.
  • Windows: Uses the bcdedit command-line utility to interface with the Windows Boot Configuration Data and update UEFI entries.
  • UEFI Shell: Provides direct command-line commands such as bcfg to edit driver and boot configurations stored in NVRAM.