The EFI (Extensible Firmware Interface) system partition or ESP is a partition on a data storage device (usually a hard disk drive or solid-state drive) that is used by computers that have the Unified Extensible Firmware Interface (UEFI). When a computer is booted, UEFI firmware loads files stored on the ESP to start operating systems and various utilities.
An ESP contains the boot loaders, boot managers, or kernel images of installed operating systems (which are typically contained in other partitions), device driver files for hardware devices present in a computer and used by the firmware at boot time, system utility programs that are intended to be run before an operating system is booted, and data files such as error logs.[1]
The EFI system partition is formatted with a file system whose specification is based on the FAT file system and maintained as part of the UEFI specification; therefore, the file system specification is independent from the original FAT specification. The actual extent of divergence is unknown:[2] Apple maintains a separate tool that should be used on Intel/x86-64 Macs,[3] while other systems use FAT utilities just fine.[4] The globally unique identifier (GUID) for the EFI system partition in the GUID Partition Table (GPT) scheme is, while its ID in the master boot record (MBR) partition-table scheme is . Both GPT- and MBR-partitioned disks can contain an EFI system partition, as UEFI firmware is required to support both partitioning schemes. Also, El Torito bootable format for CD-ROMs and DVDs is supported.
UEFI provides backward compatibility with legacy systems by reserving the first block (sector) of the partition for compatibility code, effectively creating a legacy boot sector. On legacy BIOS-based systems, the first sector of a partition is loaded into memory, and execution is transferred to this code. UEFI firmware does not execute the code in the MBR, except when booting in legacy BIOS mode through the Compatibility Support Module (CSM).
The UEFI specification requires MBR partition tables to be fully supported. However, some UEFI implementations immediately switch to the BIOS-based CSM booting upon detecting certain types of partition table on the boot disk, effectively preventing UEFI booting from being performed from EFI system partitions contained on MBR-partitioned disks.[5]
UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device is formatted with a FAT12, FAT16 or FAT32 file system, while a boot loader needs to be stored according to the standard ESP file hierarchy, or by providing a complete path of a boot loader to the system's boot manager. On the other hand, FAT32 is always expected on fixed drives.
GRUB 2, elilo and systemd-boot serve as conventional, full-fledged standalone UEFI boot managers (a.k.a. bootloader managers) for Linux. Once loaded by a UEFI firmware, they can access and boot kernel images from all devices, partitions and file systems they support, without being limited to the EFI system partition.
The mount point for the EFI system partition varies depending on the bootloader used. Older bootloaders such as GRUB 2 and lilo/elilo default to /boot/efi. Alternatively, systemd-boot prefers either /efi or /boot over /boot/efi due to potential complications with nested autofs mounts. Regardless of the mount point path, its contents are accessible after Linux is booted.[6] [7]
EFI Boot Stub makes it possible to boot a Linux kernel image without the use of a conventional UEFI boot loader. By masquerading as a PE/COFF executable image and appearing to the firmware as a UEFI application, a Linux kernel image with EFI Boot Stub enabled can be directly loaded and executed by a UEFI firmware. Such kernel images can still be loaded and run by BIOS-based boot loaders; thus, EFI Boot Stub allows a single kernel image to work in any boot environment.[8]
Linux kernel's support for the EFI Boot Stub is enabled by turning on option CONFIG_EFI_STUB (EFI stub support) during the kernel configuration.[9] It was merged into version 3.3 of the Linux kernel mainline, released on March 18, 2012.[10]
Systemd-boot is a simple UEFI boot manager that loads and runs configured EFI images, accessing only the EFI system partition. Configuration file fragments, kernel images and initrd images are required to reside on the EFI system partition, as systemd-boot does not provide support for accessing files on other partitions or file systems. Linux kernels need to be built with CONFIG_EFI_STUB=y so they can be directly executed as UEFI images.[11]
On Apple Mac computers using Intel x86-64 processor architecture, the EFI system partition is initially left blank and unused for booting into macOS.[12] [13]
However, the EFI system partition is used as a staging area for firmware updates[14] and for the Microsoft Windows bootloader for Mac computers configured to boot into a Windows partition using Boot Camp.[15]
Custom Apple UEFI firmware named iBoot controls the logic for finding and loading bootloaders. iBoot will select the desired bootloader (potentially configured via Startup Keyboard Combinations or NVRAM), optionally falling back to either the internal macOS Installation, or a recovery system called recoveryOS.[16]
Older pre-UEFI Apple–Intel architecture machines required the EFI system partition to be formatted in HFS+. Third-party bootloaders needed to be "blessed" by a special ioctl command before becoming bootable by the firmware, a relic of the System Folder blessing from Classic Mac OS. There are otherwise no limitations to what kinds of EFI operating system or bootloader an Intel-based Apple computer can run.[17] [18]
Devices using Apple silicon (AArch64) such as iPhones, iPads and all Mac computers from 2023 onward do not contain EFI/UEFI functionality and subsequently do not use EFI system partitions.[19] [20]
UEFI support in Windows began in 2008 with Windows Vista® SP1.[21]
The Windows boot manager is located at the subfolder of the EFI system partition.[22]
On Windows XP 64-Bit Edition and later, access to the EFI system partition is obtained by running the command. Mounts the EFI system partition on the specified drive. Available on Itanium-based computers only.[23]
/EFI directory on an EFI system partition