EFI system partition
The EFI system partition (also called ESP) is an OS independent partition that acts as the storage place for the UEFI boot loaders, applications and drivers to be launched by the UEFI firmware. It is mandatory for UEFI boot.
Check for an existing partition
If you are installing Arch Linux on an UEFI-capable computer with an installed operating system, like Windows 10 for example, it is very likely that you already have an EFI system partition.
To find out the disk partition scheme and the system partition, use fdisk as root on the disk you want to boot from:
# fdisk -l /dev/sdx
The command returns:
- The disk's partition table: it indicates
Disklabel type: gptif the partition table is GPT orDisklabel type: dosif it is MBR. - The list of partitions on the disk: Look for the EFI system partition in the list, it is usually at least 100 MiB in size and has the type
EFI SystemorEFI (FAT-12/16/32). To confirm this is the ESP, mount it and check whether it contains a directory namedEFI, if it does this is definitely the ESP.
If you found an existing EFI system partition, simply proceed to #Mount the partition. If you did not find one, you will need to create it, proceed to #Create the partition.
Create the partition
The following two sections show how to create an EFI system partition (ESP).
The partition size should provide adequate space for storing boot loaders and other files required for booting.
It is recommended to make the partition 1 GiB in size to ensure it has adequate space for multiple kernels or unified kernel images, a boot loader, firmware updates files and any other operating system or OEM files. If still in doubt, 4 GiB ought to be enough for anybody, e.g., for tools like Limine bootloader with Snapper integration for Btrfs, which supports creating multiple bootable snapshots.
- For early and/or buggy UEFI implementations the size of at least 512 MiB might be needed.[1]
- If you plan to mount the partition to /boot and will not install more than one kernel, then 400 MiB will be sufficient.
- When dual booting with Windows, the size should be at least 300 MiB for drives with a 4096 logical sector size (Advanced Format 4Kn drives)[2] or at least 100 MiB otherwise.[3]
- To ensure the partition can be formatted to FAT32, it should be at least 36 MiB on drives with 512 byte logical sector size and 260 MiB on drives with 4096 logical sector size.[4]
- If none of these are relevant issues, the partition size can be as small as 2 MiB, in which case it could house nothing more than a boot loader.
GPT partitioned disks
EFI system partition on a GUID Partition Table is identified by the partition type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B.
Choose one of the following methods to create an ESP for a GPT partitioned disk:
- fdisk: Create a partition and use the
tcommand to change its partition type toEFI Systemusing the aliasuefi. - gdisk: Create a partition with partition type
EF00. - GNU Parted: Create a partition with
fat32as the file system type and set theespflag on it.
After creating the partition, it should be formatted with a file system. Proceed to the #Format the partition section below.
MBR partitioned disks
- Some firmware might not support UEFI/MBR booting due to it not being supported by Windows Setup.
- bootctl does not support installing systemd-boot to an MBR partitioned disk; see systemd issue 1125.
See also Partitioning#Choosing between GPT and MBR for the limits of MBR and the advantages of GPT in general.
EFI system partition on a Master Boot Record partition table is identified by the partition type ID EF.
Choose one of the following methods to create an ESP for a MBR partitioned disk:
- fdisk: Create a primary partition and and use the
tcommand to change its partition type toEFI (FAT-12/16/32). - GNU Parted: Create a primary partition with
fat32as the file system type and set theespflag on it.
After creating the partition, it should be formatted with a file system. Proceed to the #Format the partition section below.
Format the partition
The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see UEFI specification version 2.10, section 13.3.1.1), but any conformant vendor can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system.
To prevent potential issues with other operating systems and since the UEFI specification says that UEFI "encompasses the use of FAT32 for a system partition, and FAT12 or FAT16 for removable media"[5], it is recommended to use FAT32. Use the mkfs.fat(8) utility from dosfstools:
# mkfs.fat -F 32 /dev/sdxY
If you get the message WARNING: Not enough clusters for a 32 bit FAT! and you cannot create a larger ESP, reduce cluster size with mkfs.fat -s2 -F32 ... or -s1; otherwise the partition may be unreadable by UEFI. See mkfs.fat(8) for supported cluster sizes.
For partitions smaller than 32 MiB using FAT32 may not be possible. In which case, format it to FAT16 or even FAT12. For example, a 2 MiB ESP will only be able to support FAT12:
# mkfs.fat -F 12 /dev/sdxY
Mount the partition
The kernels, initramfs files, and, in most cases, the processor's microcode, need to be accessible by the boot loader or UEFI itself to successfully boot the system. Thus if you want to keep the setup simple, your boot loader choice limits the available mount points for EFI system partition.
/boot, make sure to not rely on the systemd automount mechanism (including that of systemd-gpt-auto-generator) during kernel upgrades. Always mount it manually prior to any system or kernel update, otherwise you may not be able to mount it after the update, locking you in the currently running kernel with no ability to update the copy of kernel on the ESP.
Alternatively preload the required kernel modules on boot, e.g.:
/etc/modules-load.d/vfat.conf
vfat nls_cp437 nls_ascii
Typical mount points
The three typical scenarios for mounting the EFI system partition are:
- mount the ESP to
/boot:- This facilitates system maintenance and administration, as
/bootis the default path where microcode packages place the CPU microcode initramfs files and where mkinitcpio places kernels and initramfs images. - This ensures that the above files are accessible to most boot loaders, as not all of them can access files on other volumes.
- This prevents setting file-specific permissions and/or extended attributes, as FAT sets global permissions at mount time
- This increases the size requirement for the ESP, as files normally installed in
/bootwill join the EFI-related ones. - In the case of dual-booting, this exposes the OS-specific boot files to potentially hazardous manipulation from other OSes.
- This makes encrypting /boot impossible, as EFI-related files have to be accessible by the firmware.
- This facilitates system maintenance and administration, as
- mount the ESP to
/efi:- It ensures a separation of concerns between OS- and EFI-related files, which may include other OSes' files better left alone.
- It avoids increasing the size requirement of the ESP by not placing the files installed to
/bootin it: only the EFI binaries (the boot loader (and optionally drivers) and/or the unified kernel image) will be stored on the ESP, which saves storage space. - It allows to preserve Linux-specific filesystem permissions for files residing in
/boot, avoiding FAT limitations. - It allows to mount separately the ESP according to the need, e.g. only when upgrading the boot loader.
- If using system encryption with the appropriate setup, it allows to leave only a few required files unencrypted while
/bootremains protected: this can be useful for unified kernel images or boot loaders that have file system drivers capable of accessing the kernel(s) and files that are stored elsewhere.
- mount the ESP to
/efiand additionally mount an "Extended Boot Loader Partition" (XBOOTLDR) to/boot. This can be useful when a previously created ESP is too small to hold multiple boot loaders and/or kernels but the ESP cannot be easily resized (such as when installing Linux after Windows to dual boot). This method is supported by at least systemd-boot.
Alternative mount points
If you do not use one of the #Typical mount points, you will need to copy your boot files to ESP (referred to hereafter as esp).
# mkdir -p esp/EFI/arch # cp -a /boot/vmlinuz-linux esp/EFI/arch/ # cp -a /boot/initramfs-linux.img esp/EFI/arch/ # cp -a /boot/initramfs-linux-fallback.img esp/EFI/arch/
Furthermore, you will need to keep the files on the ESP up-to-date with later kernel updates. Failure to do so could result in an unbootable system. The following sections discuss several mechanisms for automating it.
Using bind mount
Instead of mounting the ESP itself to /boot, you can mount a directory of the ESP to /boot using a bind mount (see mount(8)). This allows pacman to update the kernel directly while keeping the ESP organized to your liking.
/boot/). See the forum post [8].Just like in #Alternative mount points, copy all boot files to a directory on your ESP, but mount the ESP outside /boot. Then bind mount the directory:
# mount --bind esp/EFI/arch /boot
After verifying success, edit your Fstab to make the changes persistent:
/etc/fstab
esp/EFI/arch /boot none defaults,bind 0 0
Using systemd
Systemd features event triggered tasks. In this particular case, the ability to detect a change in path is used to sync the EFISTUB kernel and initramfs files when they are updated in /boot/. The file watched for changes is initramfs-linux-fallback.img since this is the last file built by mkinitcpio, to make sure all files have been built before starting the copy. The systemd path and service files to be created are:
/etc/systemd/system/efistub-update.path
[Unit] Description=Copy EFISTUB Kernel to EFI system partition [Path] PathChanged=/boot/initramfs-linux-fallback.img [Install] WantedBy=multi-user.target WantedBy=system-update.target
/etc/systemd/system/efistub-update.service
[Unit] Description=Copy EFISTUB Kernel to EFI system partition [Service] Type=oneshot ExecStart=/usr/bin/cp -af /boot/vmlinuz-linux esp/EFI/arch/ ExecStart=/usr/bin/cp -af /boot/initramfs-linux.img esp/EFI/arch/ ExecStart=/usr/bin/cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/
Then enable and start efistub-update.path.
ExecStart=/usr/bin/sbsign --key /path/to/db.key --cert /path/to/db.crt --output esp/EFI/arch/vmlinuz-linux /boot/vmlinuz-linux
Using filesystem events
Filesystem events can be used to run a script syncing the EFISTUB Kernel after kernel updates. An example with incron follows.
/usr/local/bin/efistub-update
#!/bin/sh cp -af /boot/vmlinuz-linux esp/EFI/arch/ cp -af /boot/initramfs-linux.img esp/EFI/arch/ cp -af /boot/initramfs-linux-fallback.img esp/EFI/arch/
/boot/initramfs-linux-fallback.img is the file to watch. The second parameter IN_CLOSE_WRITE is the action to watch for. The third parameter /usr/local/bin/efistub-update is the script to execute./etc/incron.d/efistub-update.conf
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
In order to use this method, enable the incrond.service.
Using mkinitcpio preset
As the presets in /etc/mkinitcpio.d/ support shell scripting, the kernel and initramfs can be copied by just editing the presets.
Replacing the mkinitcpio hook
Edit the file /etc/mkinitcpio.d/linux.preset:
/etc/mkinitcpio.d/linux.preset
# mkinitcpio preset file for the 'linux' package
# Directory to install the kernel, the initramfs...
ESP_DIR="esp/EFI/arch"
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
PRESETS=('default' 'fallback')
#default_config="/etc/mkinitcpio.conf"
default_image="${ESP_DIR}/initramfs-linux.img"
default_options=""
#fallback_config="/etc/mkinitcpio.conf"
fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"
fallback_options="-S autodetect"
To test that, just run:
# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img # mv /boot/vmlinuz-linux esp/EFI/arch/ # mkinitcpio -p linux
Another example
/etc/mkinitcpio.d/linux.preset
ESP_DIR="esp/EFI/arch"
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
PRESETS=('default')
default_config="/etc/mkinitcpio.conf"
default_image="$ESP_DIR/initramfs-linux$suffix.img"
/etc/mkinitcpio.d/linux-zen.preset
suffix='-zen' source /etc/mkinitcpio.d/linux.preset
Using a mkinitcpio post hook
A mkinitcpio post hook can be used to copy kernels and initramfs images to a desired directory after the initramfs is generated.
Create the following file and make it executable:
/etc/initcpio/post/copy-kernel-and-initramfs
#!/usr/bin/env bash
kernel="$1"
initrd="$2"
target_dir="esp/EFI/arch"
files_to_copy=()
for file in "$kernel" "$initrd"; do
if [[ -n "$file" ]] && ! cmp -s -- "$file" "${target_dir}/${file##*/}"; then
files_to_copy+=("$file")
fi
done
(( ! ${#files_to_copy[@]} )) && exit 0
cp -af -- "${files_to_copy[@]}" "${target_dir}/"
Using pacman hook
A last option relies on the pacman hooks that are run at the end of the transaction.
The first file is a hook that monitors the relevant files, and it is run if they were modified in the former transaction.
/etc/pacman.d/hooks/999-kernel-efi-copy.hook
[Trigger] Type = Path Operation = Install Operation = Upgrade Target = usr/lib/modules/*/vmlinuz Target = usr/lib/initcpio/* Target = boot/*-ucode.img [Action] Description = Copying linux and initramfs to EFI directory... When = PostTransaction Exec = /usr/local/bin/kernel-efi-copy.sh
The second file is the script itself. Create the file and make it executable:
/usr/local/bin/kernel-efi-copy.sh
#!/bin/sh
#
# Copy kernel and initramfs images to EFI directory
#
ESP_DIR="esp/EFI/arch"
for file in /boot/vmlinuz*
do
cp -af "$file" "$ESP_DIR/$(basename "$file").efi"
[ $? -ne 0 ] && exit 1
done
for file in /boot/initramfs*
do
cp -af "$file" "$ESP_DIR/"
[ $? -ne 0 ] && exit 1
done
[ -e /boot/intel-ucode.img ] && cp -af /boot/intel-ucode.img "$ESP_DIR/"
[ -e /boot/amd-ucode.img ] && cp -af /boot/amd-ucode.img "$ESP_DIR/"
exit 0
Tips and tricks
Replace the partition with a larger one
On a disk with a preexisting operating system, the EFI system partition may be smaller than recommended in #Create the partition. E.g. Windows Setup creates a measly 100 MiB EFI system partition on non-4Kn drives.
In such cases, it may be a good idea to create a new, larger EFI system partition to prevent running out of space on it.
Free up space for a new partition in Windows
In Windows, partitions can be either managed graphically with Disk Management (diskmgmt.msc) or from the command line with the diskpart.exe utility.
Run diskmgmt.msc as Administrator.
- Right click on the "(C:)" partition (the only one of the default Windows-created partitions which can be resized online) and select Shrink Volume....
- Enter
4096as the amount to shrink and click Shrink.
There should now be a 4 GiB unallocated space after the "(C:)" partition.
Boot into Arch Linux or the Arch Linux installation medium to proceed to creating a new partition.
Delete the old partition and create a new one
First, make sure to backup the contents of the EFI system partition. For example, with esp being its mountpoint:
# cp -a esp /esp_backup
Unmount the EFI system partition:
# umount esp
esp.mount and esp.automount units to prevent systemd from automounting it again.Run blkid and take note of the UUID and PARTUUID values. They will later be reused for the new partition.
# blkid
/dev/sdxY: UUID="XXXX-XXXX" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY"
Delete the old partition using sgdisk from gptfdisk:
# sgdisk --delete=Y /dev/sdx
Create a new partition in the largest unallocated space while reusing the old PARTUUID and PARTLABEL:
# sgdisk --align-end --largest-new=0 --typecode=0:ef00 --change-name=0:'EFI system partition' --partition-guid=0:YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY /dev/sdx
Confirm the new, 4 GiB in size, EFI system partition is created by listing the partitions with fdisk:
# fdisk -l /dev/sdx
... Device Start End Sectors Size Type /dev/sdx1 158099456 166488063 8388608 4G EFI System /dev/sdx2 206848 239615 32768 16M Microsoft reserved /dev/sdx3 239616 158099455 157859840 75.3G Microsoft basic data /dev/sdx4 166488064 167768063 1280000 625M Windows recovery environment /dev/sdx5 167768064 176156671 8388608 4G Linux swap /dev/sdx6 176156672 243265535 67108864 32G Linux root (x86-64) Partition table entries are not in disk order.
Partition numbers are not resorted when deleting and creating partitions, so the EFI system partition number on the disk will likely be the same as before.
Format the partition to FAT32 reusing the old UUID (while removing the dash from it):
# mkfs.fat -F 32 -i XXXXXXXX /dev/sdxY
Finally, mount the new partition and restore its contents from backup:
# mount /dev/sdxY esp # cp -a /esp_backup/. esp/
If you previously stopped esp.automount, start it again.
Sacrifice an adjacent swap partition to enlarge the ESP
If there is a swap partition right after the EFI system partition, you can sacrifice it to give space for enlarging the EFI system partition. E.g. with a layout similar to:
# fdisk -l /dev/sdx
... Device Start End Sectors Size Type /dev/sdx1 2048 616447 614400 300M EFI System /dev/sdx2 616448 9005055 8388608 4G Linux swap /dev/sdx3 9005056 125827071 116822016 55.7G Linux root (x86-64)
First, deactivate the swap partition and remove it from fstab.
Use fdisk to delete the swap partition and enlarge the EFI system partition.
- Run:
# fdisk -l /dev/sdx
- Use the
dcommand to delete the swap partition (partition number2in the example layout above). - Use the
ecommand to enlarge the EFI system partition (partition number1in the example layout above). Use the suggested default value for the new size and pressEnter. - Write changes to disk and exit via the
wcommand.
After the partition is resized, you need to resize the file system in it. Since fatresize(1) does not work and libparted cannot resize FAT volumes of certain sizes, the only option is to backup the files from the existing file system and create a new one that takes up all space of the partition.
Take note of the file system UUID to allow reusing it for the new file system:
$ lsblk -dno UUID /dev/sdxY
XXXX-XXXX
Backup the contents of the EFI system partition. For example, with esp being its mountpoint:
# cp -a esp /esp_backup
Unmount the EFI system partition:
# umount esp
esp.mount and esp.automount units to prevent systemd from automounting it again.Wipe the file system signature from the partition to avoid any artifacts from the old file system:
# wipefs -af /dev/sdxY
Format the partition to FAT32 reusing the old UUID (while removing the dash from it):
# mkfs.fat -F 32 -i XXXXXXXX /dev/sdxY
Finally, mount the new partition and restore its contents from backup:
# mount /dev/sdxY esp # cp -a /esp_backup/. esp/
If you previously stopped esp.automount, start it again.
Now that the swap partition is gone, set up swap on a swap file.
Troubleshooting
ESP on software RAID1
It is possible to make the ESP part of a RAID1 array, but doing so brings the risk of data corruption, and further considerations need to be taken when creating the ESP. See [9] and [10] for details and UEFI booting and RAID1 for an in-depth guide with a solution.
The key part is to use --metadata 1.0 in order to keep the RAID metadata at the end of the partition, otherwise the firmware will not be able to access it:
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sdaX /dev/sdbY
Alternatively, as the ESP is not often updated, a secondary ESP can be managed by copying the primary ESP to the secondary one on a different disk during relevant updates. A boot entry for the secondary ESP can then be added manually using efibootmgr. See the debian wiki for an implementation example. Note that while this avoids some risks of the RAID approach, it only works when using a single OS.
Firmware does not see the EFI directory
If you give the FAT file system a volume name (i.e. file system label), be sure to name it something other than EFI. That can trigger a bug in some firmwares (due to the volume name matching the EFI directory name) that will cause the firmware to act like the EFI directory does not exist.