EFI System partition

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The EFI System partition (ESP) is a partition on a data storage device that is used by machines that adhere to the Unified Extensible Firmware Interface (UEFI).

It contains the boot loader programs for all operating systems installed (in other partitions) on the device, device driver files (used by the firmware at boot time) for other devices, 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 using the FAT12, FAT16 or FAT32 file system. The globally unique identifier for the EFI System partition in the GUID Partition Table scheme is C12A7328-F81F-11D2-BA4B-00A0C93EC93B, while its ID in the MBR partition table scheme is 0xEF. Both GPT and MBR-partitioned disks can contain an EFI System partition, as UEFI firmwares are required to support both partitioning schemes. Also, El Torito bootable format for CD-ROMs and DVDs is supported.[1]

It supports 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 firmwares do not execute the code in the Master Boot Record (MBR), except when booting in legacy BIOS mode through the Compatibility Support Module (CSM).[1]

Despite the fact MBR partition tables are required to be fully supported within the UEFI specification,[1] some UEFI firmwares immediately switch to the BIOS-based CSM booting depending on the type of boot disk's partition table, thus preventing UEFI booting to be performed from EFI System partitions on MBR-partitioned disks.[2]

Booting from removable media such as USB flash drives is supported. A removable device needs to be formated using the FAT12, FAT16 or FAT32 file system, and booting can be performed either by storing a boot loader according to the standard ESP file hierarchy, or by providing a complete path of a boot loader to the system's boot manager.[1]



GRUB 2 and elilo are serving as conventional, full-fledged and standalone UEFI boot managers for Linux. They both allow accessing and booting kernel images outside the EFI System partition.

EFI Boot Stub makes it possible to boot a Linux kernel without the use of a conventional UEFI boot loader. It allows an x86 kernel image to be loaded and executed directly by the UEFI firmware, masquerading itself as a PE/COFF image and appearing to the firmware as an UEFI application. Both BIOS and UEFI boot loaders can still load and run the same kernel image, thereby allowing a single kernel image to work in any boot environment.[3]

Support for the EFI Boot Stub is enabled by turning on the option CONFIG_EFI_STUB (EFI stub support) during kernel configuration.[4] It was merged into the Linux kernel mainline in kernel version 3.3, released on 18 March 2012.[5]

Gummiboot is a simple UEFI boot manager which executes configured UEFI 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 there is no support for accessing files on other partitions or file systems. Linux kernels need to be built with CONFIG_EFI_STUB enabled so they can be directly executed as an UEFI image.[6]

Mount point for the EFI System partition is usually /boot/efi, where its content is accessible after Linux is booted.[7]


Microsoft recommends that when partitioning a disk, the EFI System partition be the first partition on the disk.[8] This is not a requirement of the EFI specification itself. On Windows XP 64-Bit Edition and later, access to the EFI System partition is obtained by running the mountvol /s command.


On Apple–Intel architecture Macintosh computers, the EFI partition is initially blank and not used for booting.[9] However, the EFI partition is used as a staging area for firmware updates;[10] specifically, it places a firmware flash utility (EFI binary) and data file (FD – "Firmware Device"[11]) in the directory EFI/APPLE/FIRMWARE which is then run when rebooting the system in "flash firmware" mode.[12]

If deleted, the system will still boot, and the boot manager will still allow users to choose whether to start a Boot Camp partition or the default Mac OS X, but firmware updates will fail.

See also[edit]


  1. ^ a b c d e "UEFI Specifications (version 2.4 and older)" (PDF). Unified EFI, Inc. June 2013. Retrieved 2013-09-25. 
  2. ^ "UEFI system booting from MBR partition table and GRUB legacy". Arch Linux Forums. June 2012. Retrieved 2013-10-06. 
  3. ^ "EFI Boot Stub (Linux kernel documentation)". kernel.org. Retrieved 2013-10-06. 
  4. ^ "arch/x86/Kconfig (3.11.1)". CONFIG_EFI_STUB (line #1575). kernel.org. Retrieved 2013-10-06. 
  5. ^ "Linux 3.3". 1.10. EFI boot support. kernelnewbies.org. 2012-03-18. Retrieved 2013-10-06. 
  6. ^ "gummiboot: Simple UEFI Boot Manager". freedesktop.org. Retrieved 2013-10-06. 
  7. ^ "UEFI - Community Ubuntu Documentation". ubuntu.com. 2013-12-21. Retrieved 2013-12-27. 
  8. ^ "EFI System Partition". Windows and GPT FAQ. 
  9. ^ rEFIt: Myths and Facts About Intel Macs – Myth: Mac OS X requires a hidden EFI System Partition
  10. ^ "Firmware updates for Intel-based Macs require a GUID partition scheme". Apple Knowledgebase. 
  11. ^ Zero to OS in a Flash: "Firmware device (FD) is a persistent physical repository that contains firmware code and data."
  12. ^ ubuntu forums: iMac EFI Firmware Update 1.2, September 29th, 2007

External links[edit]