The EFI system partition (ESP) is a partition on a data storage device (usually

a hard disk drive or solid-state drive) that is used by computers adhering to th

e Unified Extensible Firmware Interface (UEFI). When a computer is powered up an
d booted, UEFI firmware loads files stored on the ESP to start installed operati
ng systems and various utilities. An ESP needs to be formatted with a file syste
m 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.[1][2]
ESP contains the boot loaders or kernel images for all installed operating syste
ms (which are contained in other partitions on the same or any other local stora
ge device), device driver files for hardware devices present in a computer and u
sed by the firmware at boot time, system utility programs that are intended to b
e run before an operating system is booted, and data files such as error logs.
The EFI System partition needs to be formatted with a file system whose specific
ation is maintained as part of the UEFI specification; the file system itself is
based on the FAT file system but is independent from the original FAT specifica
tion.[1] The globally unique identifier (GUID) for the EFI System partition in t
he GUID Partition Table (GPT) scheme is C12A7328-F81F-11D2-BA4B-00A0C93EC93B, wh
ile its ID in the MBR partition table scheme is 0xEF. Both GPT- and MBR-partitio
ned disks can contain an EFI System partition, as UEFI firmware is required to s
upport both partitioning schemes. Also, El Torito bootable format for CD-ROMs an
d DVDs is supported.[3]
UEFI provides backward compatibility with legacy systems by reserving the first
block (sector) of the partition for compatibility code, effectively creating a l
egacy 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 Master Boot Record (MBR), except when booting i
n legacy BIOS mode through the Compatibility Support Module (CSM).[3]
The UEFI specification requires MBR partition tables to be fully supported.[3] H
owever, some UEFI implementations immediately switch to the BIOS-based CSM booti
ng upon detecting certain types of partition table on the boot disk, effectively
preventing UEFI booting to be performed from EFI System partitions contained on
MBR-partitioned disks.[4]
UEFI firmware supports booting from removable storage devices such as USB flash
drives. For that purpose, a removable device needs to be 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 load
er to the system's boot manager.[3]
Linux
See also: UEFI and Linux disk device compatibility
GRUB 2 and elilo serve as conventional, full-fledged standalone UEFI boot manage
rs for Linux. Once loaded by a UEFI firmware, they both can access and boot kern
el images from all devices, partitions and file systems they support, without be
ing limited to the EFI System partition.
EFI Boot Stub makes it possible to boot a Linux kernel image without the use of
a conventional UEFI boot loader. By masquerading itself as a PE/COFF image and a
ppearing to the firmware as a UEFI application, an x86 kernel image with EFI Boo
t Stub enabled can be directly loaded and executed by a UEFI firmware. Such kern
el 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.[5]
Linux kernel's support for the EFI Boot Stub is enabled by turning on option CON

FIG_EFI_STUB (EFI stub support) during the kernel configuration.[6] It was merge
d into version 3.3 of the Linux kernel mainline, released on March 18, 2012.[7]
Gummiboot (a.k.a. systemd-boot) is a simple UEFI boot manager that loads and run
s configured UEFI images, accessing only the EFI System partition. Configuration
file fragments, kernel images and initrd images are required to reside on the E
FI System partition, as Gummiboot does not provide support for accessing files o
n other partitions or file systems. Linux kernels need to be built with CONFIG_E
FI_STUB enabled so they can be directly executed as UEFI images.[8]
The mount point for the EFI System partition is usually /boot/efi, where its con
tent is accessible after Linux is booted.[9]
Windows
Microsoft recommends that when partitioning a disk, the EFI System partition be
the first partition on the disk.[10] This is not a requirement of the EFI specif
ication itself. On Windows XP 64-Bit Edition and later, access to the EFI System
partition is obtained by running the mountvol /s command.
Apple Intel
On Macintosh computers based on Apple Intel architecture, the EFI system partition i
s initially left blank and unused for booting.[11] However, the EFI system parti
tion is used as a staging area for firmware updates;[12] specifically, a firmwar
e update places a cryptographically signed firmware payload (typically ending on
LOCKED.scap) in the directory EFI/APPLE/FIRMWARE, which is applied when the sys
tem is rebooted. The presence of this payload is automatically detected by the p
roprietary system firmware; alternatively, an NVRAM or EFI variable can be set.[
citation needed]
The system will still boot after the EFI partition is deleted, in which case the
boot manager will allow users to choose whether to start a Boot Camp partition
or the default Mac OS X, but firmware updates will fail.
From: https://en.wikipedia.org/wiki/EFI_system_partition