EFI System Partition
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)
For creation instructions see Handbook.
parted (sys-block/parted) will show it with the boot, esp flags:
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:
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:
mkfs.fat -F 32 /dev/sda1
256 MiB should be enough for some primary bootloader payloads such as EFI stub kernels or Windows.
Recently (in 2023) the Gentoo Handbook changed the ESP's size example to 1GiB. In particular if a user plans to use unified kernel images such a bigger partition can help.
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:
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:
rc-update add autofs default
To use the automounter before rebooting, start it manually:
There is no need to add these partitions to /etc/fstab.
There is a standard layout for the ESP. Vendors and distributions are supposed to put their stuff into vendor specific directories.
tree -L 3 /efi
/efi └── EFI ├── Boot │ └── bootx64.efi ├── Gentoo │ └── bzImage-4.9.76-r1.efi └── Microsoft ├── Boot └── Recovery
Here the Microsoft subtree - and also the Boot subtree - was created by an earlier installation of Windows 10 Creators Update. 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 usually provide a boot menu and a configuration tool for creating, sorting or deleting boot items. The content 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.
Alternatively, efibootmgr can be used for generating the UEFI boot items.
- 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.
- FAT — filesystem originally created for use with MS-DOS (and later pre-NT Microsoft Windows).
- EFI stub — provides instructions on configuring and installing kernels in the EFI System Partition (ESP) of a computer running in EFI mode
- efibootmgr — a tool for managing UEFI boot entries.
- EFI Shell The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders.
- REFInd — a boot manager for EFI and UEFI platforms forked from and successor to rEFIt.