How OS Installers Populate the EFI System Partition

During a fresh UEFI installation, an operating system installer configures the system to boot modern hardware by setting up an EFI System Partition (ESP). This process involves identifying or creating a dedicated FAT32 partition, structuring a standardized directory hierarchy, copying architecture-specific bootloader binaries and configuration files, and registering the newly installed operating system directly into the motherboard's non-volatile memory (NVRAM) via UEFI runtime services.

1. Partition Verification and Creation

The installer first scans the target storage drive, which must use the GUID Partition Table (GPT) scheme for standard UEFI boot. It searches for an existing ESP by looking for a specific globally unique identifier (GUID): C12A7328-F81F-11D2-BA4B-00A0C93EC93B.

  • If an ESP exists: (For example, in a dual-boot scenario), the installer reuses the existing partition without formatting it, preserving existing boot files from other operating systems.
  • If no ESP exists: The installer creates a new partition, typically ranging from 100 MB to 512 MB in size. It sets the partition type GUID to the official ESP identifier and formats it with a FAT32 (or occasionally FAT16) file system, as required by the UEFI specification.

2. Mounting the Partition

Once the partition is ready, the installer mounts the ESP into the temporary live installation environment:

  • Linux installers typically mount the partition at /target/boot/efi or directly at /target/boot.
  • Windows Setup (WinPE) assigns the volume a hidden status or mounts it to a temporary path via the volume management API.

3. Deploying Directory Structures and Binaries

UEFI firmware looks for boot loaders under a standardized directory tree. The installer creates a top-level directory named EFI and populates it based on standard conventions:

  • Vendor Directories: The installer creates a subdirectory named after the distribution or vendor (e.g., /EFI/Microsoft/Boot/, /EFI/ubuntu/, or /EFI/fedora/).
  • Bootloader Files: The installer copies primary bootloaders and supporting files into this vendor directory:
    • Windows: Copies bootmgfw.efi along with the Boot Configuration Data (BCD) store and language resource files.
    • Linux: Copies modern secure boot shims (shimx64.efi), the GRUB/systemd-boot binary (grubx64.efi), and minimal configuration files or modules.
  • Fallback Executable: Most installers write a copy of their primary bootloader to /EFI/BOOT/BOOTX64.EFI (on x86-64 hardware). This file serves as the default fallback path if NVRAM entries become corrupted or missing, enabling the firmware to boot the drive even without explicit configuration.

4. Updating Firmware NVRAM Entries

After placing the files, the installer must instruct the motherboard’s UEFI firmware where to find the new bootloader. It does this by communicating directly with the motherboard using UEFI Runtime Services.

  1. Calling SetVariable: In Linux, tools like efibootmgr interface with the kernel's efivarfs to execute the UEFI SetVariable call. On Windows, setup tools execute the equivalent API calls via bcdedit or native deployment binaries.
  2. Writing Boot#### Variables: The installer creates a new variable, such as Boot0001, containing the partition's UUID, the file path to the loader (e.g., \EFI\ubuntu\shimx64.efi), and a human-readable description (e.g., "Ubuntu").
  3. Updating BootOrder: The installer modifies the global BootOrder NVRAM variable to place the newly created boot entry at the beginning of the list, ensuring the newly installed operating system boots first upon reboot.