Jump to content

EFI system partition

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Voidxor (talk | contribs) at 00:15, 23 January 2016 (→top: There's more than one EFI system partition in the world, but only one on most PCs. That makes it a non-proper noun and thus lowercase per WP:LOWERCASE.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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 the Unified Extensible Firmware Interface (UEFI). When a computer is powered up and booted, UEFI firmware loads files stored on the ESP to start installed operating systems and various utilities. An ESP needs to be 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.[1][2]

ESP contains the boot loader programs for all installed operating systems (which are contained in other partitions on the same or any other local storage device), 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.[3]

Overview

See also: UEFI § UEFI booting, and UEFI § CSM booting

The EFI System partition needs to be formatted with a file system whose specification 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 specification.[1] The globally unique identifier (GUID) for the EFI System partition in the GUID Partition Table (GPT) 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 firmware is required to support both partitioning schemes. Also, El Torito bootable format for CD-ROMs and 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 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 Master Boot Record (MBR), except when booting in legacy BIOS mode through the Compatibility Support Module (CSM).[3]

The UEFI specification requires MBR partition tables to be fully supported.[3] 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 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 loader to the system's boot manager.[3]

Usage

Linux

See also: UEFI and Linux disk device compatibility

GRUB 2 and elilo serve as conventional, full-fledged standalone UEFI boot managers for Linux. Once loaded by a UEFI firmware, they both can access and boot kernel images from all devices, partitions and file systems they support, without being 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 appearing to the firmware as a UEFI application, an x86 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.[5]

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.[6] It was merged 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 runs 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 Gummiboot does not provide 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 UEFI images.[8]

The mount point for the EFI System partition is usually /boot/efi, where its content 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 specification 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 Apple–Intel architecture Macintosh computers, the EFI partition is initially blank and not used for booting.[11] However, the EFI partition is used as a staging area for firmware updates;[12] specifically, it places a firmware flash utility (EFI binary) and data file (FD – "Firmware Device"[13]) in the directory EFI/APPLE/FIRMWARE which is then run when rebooting the system in "flash firmware" mode.[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.

See also

References

  1. ^ a b "UEFI Specification Version 2.5, Section 12.3 File System Format" (PDF). UEFI.org. April 2015. pp. 536, 537. Retrieved 2015-05-29. The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable. Conformance to the EFI specification and its associate reference documents is the only definition of FAT that needs to be implemented to support EFI. To differentiate the EFI file system from pure FAT, a new partition file system type has been defined.
  2. ^ "Technical Note TN2166: Secrets of the GPT". Developer.Apple.com. 2006-11-06. Retrieved 2015-05-06.
  3. ^ a b c d e "UEFI Specifications (versions 2.5 and older)" (PDF). UEFI.org. April 2015. Retrieved 2015-05-29.
  4. ^ "UEFI system booting from MBR partition table and GRUB legacy". archlinux.org. June 2012. Retrieved 2013-10-06.
  5. ^ "Linux kernel documentation: Documentation/efi-stub.txt". Kernel.org. 2014-06-16. Retrieved 2014-11-26.
  6. ^ "Linux kernel 3.11.1 arch/x86/Kconfig: CONFIG_EFI_STUB (line #1575)". Kernel.org. Retrieved 2013-10-06.
  7. ^ "Linux kernel 3.3: 1.10. EFI boot support". KernelNewbies.org. 2012-03-18. Retrieved 2013-10-06.
  8. ^ "gummiboot: Simple UEFI Boot Manager". FreeDesktop.org. Archived from the original on 2013-09-12. Retrieved 2016-01-22.
  9. ^ "UEFI - Community Ubuntu Documentation". Ubuntu.com. 2013-12-21. Retrieved 2013-12-27.
  10. ^ "EFI System Partition". Windows and GPT FAQ.
  11. ^ rEFIt: Myths and Facts About Intel Macs – Myth: Mac OS X requires a hidden EFI System Partition
  12. ^ "Firmware updates for Intel-based Macs require a GUID partition scheme". Apple Knowledgebase.
  13. ^ McDaniel, Daryl (2008-04-04). "Zero to OS in a Flash" (PDF). Download.Intel.com. Intel. Archived from the original (PDF) on 2011-11-10. Retrieved 2016-01-22. Firmware device (FD) is a persistent physical repository that contains firmware code and data.
Retrieved from "https://en.wikipedia.org/w/index.php?title=EFI_system_partition&oldid=701180861"