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: gpt if the partition table is GPT or Disklabel type: dos if 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 System or EFI (FAT-12/16/32). To confirm this is the ESP, mount it and check whether it contains a directory named EFI, if it does this is definitely the ESP.

Tip: To find out whether it is a FAT12, FAT16 or FAT32 file system, follow FAT#Detecting FAT type.

Warning: When dual-booting, avoid reformatting the ESP, as it may contain files required to boot other operating systems.

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).

Warning: The EFI system partition must be a physical partition in the main partition table of the disk, not under LVM or software RAID etc.

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.

Note: It is possible to use a smaller partition, but mind the potential compatibility issues:

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 t command to change its partition type to EFI System using the alias uefi.
gdisk: Create a partition with partition type EF00.
GNU Parted: Create a partition with fat32 as the file system type and set the esp flag 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

Warning: It is highly recommended to use GPT instead of MBR.

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 t command to change its partition type to EFI (FAT-12/16/32).
GNU Parted: Create a primary partition with fat32 as the file system type and set the esp flag 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.

Note: If the ESP is not mounted to /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 /boot is 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 /boot will 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.
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 /boot in 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 bootloader.
- If using system encryption with the appropriate setup, it allows to leave only a few required files unencrypted while /boot remains 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 /efi and 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.

Note:

/efi is a replacement[6][7] for the historical and now discouraged ESP mountpoint /boot/efi.
The /efi directory is not available by default, you will need to first create it before mounting the ESP to it.

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/

Note: If you use external microcode initramfs images, they will also need to be copied to the boot-entry location.

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.

Note: This requires a kernel and boot loader compatible with FAT32. This is not an issue for a regular Arch install, but could be problematic for other distributions (namely those that require symlinks in /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.

Tip: For Secure Boot with your own keys, you can set up the service to also sign the image using sbsigntools:

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/

Note: The first parameter /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 operation system, the EFI system partition may be smaller that 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 4096 as 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

Note: On an installed system, you may need to additionally stop 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 d command to delete the swap partition (partition number 2 in the example layout above).
Use the e command to enlarge the EFI system partition (partition number 1 in the example layout above). Use the suggested default value for the new size and press Enter.
Write changes to disk and exit via the w command.

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

Note: On an installed system, you may need to additionally stop 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.