EFI System Partition
The given reason is: Wrong language by mistake
If there is any reason not to delete this page, do not remove this notice, but please open a discussion on the associated talk page (this should delay deletion until the discussion is resolved).
This notice should remain for a minimum of 1 month after it was placed on the page. If discussion is still ongoing it should remain until a consensus is reached (check the talk page), at which time the page may be deleted or this notice may be removed.
If the page has only been edited by the user who nominated it for deletion and/or is in the nominator's user space, then more flexibility in the decision may be allowed.
Check the help page on deleting for more information.
The EFI system partition (ESP) is a FAT formatted partition containing the primary EFI boot loader(s) for installed operating systems.
Kernel
Advanced partition selection (CONFIG_PARTITION_ADVANCED) and EFI GUID Partition support (CONFIG_EFI_PARTITION) must be enabled:
-*- Enable the block layer --->
Partition Types --->
[*] Advanced partition selection
[*] EFI GUID Partition support
ISO8859-1 codepage must be enabled too, in order to mount the FAT EFI partition:
-*- File Systems --->
DOS/FAT/EXFAT/NT Filesystems --->
<*> VFAT (Windows-95) fs support
(437) Default codepage for FAT
(iso8859-1) Default iocharset for FAT
Native Language support --->
[*] NLS ISO 8859-1 (Latin 1; Western European Languages)
Characteristics
For creation instructions see Handbook.
parted (sys-block/parted) will show it with the boot, esp flags:
root #
parted /dev/sda print
Model: ATA SAMSUNG SSD SM84 (scsi) Disk /dev/sda: 256GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 99.6MB 98.6MB fat32 EFI System Partition boot, esp
gdisk (sys-apps/gptfdisk) will show it with partition code EF00:
root #
gdisk -l /dev/sda
GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 500118192 sectors, 238.5 GiB Logical sector size: 512 bytes Disk identifier (GUID): 1B59C2C8-8795-4625-9718-4D636B005AC1 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 500118158 Partitions will be aligned on 2048-sector boundaries Total free space is 2669 sectors (1.3 MiB) Number Start (sector) End (sector) Size Code Name 1 2048 194559 94.0 MiB EF00 EFI System Partition
Its filesystem can be created using the mkfs.fat command:
root #
mkfs.fat -F 32 /dev/sda1
Size considerations
Gentoo Handbook recommends to allocating 1 GiB for ESP, which is more than enough for any bootloader payloads like EFI stub kernels or Windows.
Mount point
Mounting the ESP to /boot/efi/, as was traditionally done, is not recommended. A nested setup complicates implementation of best-practice autofs-style mounts, as establishing the inner autofs will trigger the outer one. Mounting these partitions via autofs (and by extension keeping them unmounted whenever possible) is recommended due to the data integrity and security characteristics of VFAT file systems being effectively nonexistent.
Where bootloader support is available use /boot for the XBOOTLDR partition and /efi for the ESP. If it is not possible to do so, a monolithic ESP should be mounted at /boot; autofs-style mounts should still be used.
systemd, when partitions are configured according to the Discoverable Partitions Specification, can automatically mount the ESP used for the current boot to /boot or /efi unless a different partition is mounted there [possibly via /etc/fstab] or the mount point directory is not empty. If both ESP and XBOOTLDR exist, the /efi mount point is used.
For systemd (if not using the GPT auto generator):
UUID=56FE-81E0 /efi vfat defaults,noatime,uid=0,gid=0,umask=0077,x-systemd.automount,x-systemd.idle-timeout=600 0 2
For OpenRC, use AutoFS to mount on-demand:
root #
emerge --ask net-fs/autofs
Setup a Direct AutoFS Mount for the ESP.
/- /etc/autofs/auto.boot --timeout=600,sync,nodev
Tell AutoFS to watch for access to the paths /boot and /efi and mount them with options from device.
/boot -fstype=vfat,uid=0,gid=0,umask=0077 UUID=AB12-CD34
/efi -fstype=vfat,uid=0,gid=0,umask=0077 UUID=EF00-000A
AutoFS needs to be running to watch mountpoints:
root #
rc-update add autofs default
To use the automounter before rebooting, start it manually:
root #
/etc/init.d/autofs start
There is no need to add these partitions to /etc/fstab.
Standard layout
There is a standard layout for the ESP. Vendors and distributions are supposed to put their stuff into vendor specific directories.
user $
tree -L 3 /efi
/efi └── EFI ├── BOOT │ └── BOOTX64.EFI ├── Gentoo │ ├── grubx64.efi │ ├── initramfs-x.y.z.img │ ├── kernel-x.y.z.efi │ ├── mmx64.efi │ └── shimx64.efi ├── Linux │ └── gentoo-x.y.z.efi ├── Microsoft │ ├── Boot │ └── Recovery ├── refind │ └── refind_x64.efi └── systemd └── systemd-bootx64.efi
Here the Microsoft subtree - and also the Boot subtree[1] - was created by an earlier installation of Windows 10. The Boot subtree is the fallback directory. If UEFI can't find any vendor specific directories it will boot from here. In a multiboot environment with properly set up vendor specific subtrees the Boot subtree can be deleted.
UEFI boot items
Computers with UEFI provide a boot menu for bootloaders on the ESP. This boot menu is a function of the firmware and is not shown by default. Moreover there is no standard of how to get to the boot menu, but the most common way is to hold (or continuously press) a key on UEFI firmware initialization (also POST, power-on self test). Most UEFI firmware vendors will show the boot menu when one of the function keys on the connected keyboard is pressed. The boot menu may also be available from within the firmware setup ("BIOS setup"), which is also accessible when pressing a predefined key. Most commonly Esc, Del, F1, F2, F10, F11 and F12, and on Tablets also the Volume Up/Down keys are used to either enter the firmware setup or display the boot menu.[2] Please consult your system or mainboard manual for the exact keys and further details.
An installation tool will not only manage the bootloader and other required files on the ESP, it will also manage the addition of an "EFI boot entry". EFI boot entries, stored in NVRAM, are like the registration of the bootloader to the firmware. EFI will normally only list bootloaders with a boot entry in the boot menu, therefore it is not sufficient to only copy a bootloader or EFI executable to the ESP. Linux bootloaders will normally automatically add an EFI boot entry on installation of an (U)EFI bootloader, like e.g. GRUB with grub-install.
Alternatively, a configuration tool for creating, sorting and deleting boot items is often included on UEFI compatible operating systems. The contents of the ESP is visible to these tools and creating a boot item is like choosing the medium from a given selection, then surfing through the ESP and selecting the item, e.g bzImage-4.9.76-r1-gentoo.efi. On Linux, efibootmgr can be used for managing the UEFI boot items.
In case a bootloader is deleted from the ESP, UEFI will normally delete the EFI boot entry as well on startup, and the bootloader will no longer be available from the boot menu, even when the file is afterwards restored, i.e. copied to the same path on the ESP.
One single exception, where no EFI boot entry is required, is the removable media boot path. On internal (fixed) media, such as the internal HDD or SDD, it is also used as the fallback boot path on most UEFI systems.
Removable media
EFI bootloaders on removable media are not configured as boot entries, so tools like efibootmgr are not required. Instead the computer firmware identifies removable boot options by looking for a predefined file name unique to the system architecture in use, in a predefined path.[3]
Most (U)EFI implementations support the use of the removable media boot path as a fallback on internal drives.[4] Even though this is against specification, most systems use it as a fallback and it may even be the only usable bootloader on a system with a buggy (U)EFI. Only one such fallback bootloader is possible on a specific system (i.e. architecture), due to the standardized boot path and file names.
Architecture | Abbreviation | File name | PE executable machine type |
---|---|---|---|
x86 32-bit | IA-32 | \efi\boot\bootia32.efi | 0x14c |
x86-64 (amd64) | x64 | \efi\boot\bootx64.efi | 0x8664 |
Itanium | IA-64 | \efi\boot\bootia64.efi | 0x200 |
ARM 32-bit | AArch32 | \efi\boot\bootarm.efi | 0x01c2 |
ARM 64-bit | AArch64 | \efi\boot\bootaa64.efi | 0xAA64 |
RISC-V 32-bit | \efi\boot\bootriscv32.efi | 0x5032 | |
RISC-V 64-bit | \efi\boot\bootriscv64.efi | 0x5064 | |
RISC-V 128-bit | \efi\boot\bootriscv128.efi | 0x5128 | |
Loongson 32-bit | LoongArch32 | \efi\boot\bootloongarch32.efi | 0x6232 |
Loongson 64-bit | LoongArch64 | \efi\boot\bootloongarch64.efi | 0x6264 |
To boot from removable media, the firmware has to look for compatible bootloaders on supported devices, which can be configured in the firmware setup. Like most firmwares, (U)EFI provides a hotkey to show a boot selection (formally known as "BIOS Boot Specification" or BBS), otherwise (U)EFI will use the configured default boot entry. However, a buggy (U)EFI may default to the removable media boot path even on internal drives.
To use the removable media boot path it is sufficient to copy the EFI bootloader to the required path and file name. Should the firmware make use of this fallback, this may also remove the ability to select between configured boot entries, meaning that boot options (as listed with efibootmgr) through (U)EFI will not work. Even though every EFI bootloader can be used as fallback, it may be advisable to use a boot manager that itself has the ability to select between boot options, such as GRUB. From the above example for x64 (amd64):
root #
cp /efi/EFI/Grub/grubx64.efi /efi/EFI/boot/bootx64.efi
The FAT file system of the EFI System Partition (ESP) is not case-sensitive, but case-preserving (VFAT), while Unix is traditionally strictly case-sensitive. In the Linux kernel,
vfat
defaults to treating names case-insensitive (mount option check=r
for relaxed),[5] so the above command on the ESP will always work. Only when VFAT has been mounted with strict case checking, check=s
, the path /efi/EFI/boot/bootx64.efi may not work, as the existing files and directories could be using capital letters, e.g. /efi/EFI/BOOT or /efi/EFI/Boot (which would be different directories with strict case-sensitivity); the same goes for bootx64.efi. Running tree -L 3 /efi (when the ESP is mounted under /efi) will show the names in use on the individual system, to which the above command has to be changed accordingly.The fallback bootloader is not automatically updated! Every time e.g. GRUB is re-installed (like after a version update, which may contain security fixes), it has to be copied to the fallback boot path again, overwriting (updating) the previous version!
The boot manager included in systemd, systemd-boot (formally Gummiboot), will automatically install to the removable media boot path. When sys-apps/systemd with the boot
USE flag is updated, it is necessary to run bootctl again in order to update both bootloader files.
root #
bootctl update
See also
- Handbook:AMD64/Installation/Disks#What is the EFI System Partition (ESP)?
- UEFI — a firmware standard for boot ROM designed to provide a stable API for interacting with system hardware. On x86 it replaced the legacy BIOS.
- EFI stub — describes EFI stub kernels, i.e. kernels directly executable from UEFI.
- efibootmgr — a tool for managing UEFI boot entries.
- REFInd — a boot manager for UEFI platforms.
References
- ↑ https://wiki.debian.org/UEFI#Force_grub-efi_installation_to_the_removable_media_path
- ↑ https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode
- ↑ UEFI 2.10 Specification, 3.5.1.1 Removable Media Boot Behavior
- ↑ Debian Wiki – UEFI: Force grub-efi installation to the removable media path
- ↑ https://www.kernel.org/doc/html/v6.0/filesystems/vfat.html