EFI system partition

The EFI system partition (also called ESP) is an OS independent partition that acts as the storage place for the EFI bootloaders, applications and drivers to be launched by the UEFI firmware. It is mandatory for UEFI boot.

Related articles

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

The partition size should provide adequate space for storing boot loaders and other files required for booting.

To prevent interoperability issues with other operating systems it is recommend to make it at least 300 MiB. For early and/or buggy UEFI implementations the size of at least 512 MiB might be needed. 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 .

Choose one of the following methods to create an ESP for a GPT partitioned disk:

  • fdisk: Create a partition with partition type EFI System.
  • gdisk: Create a partition with partition type .
  • GNU Parted: Create a partition with 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

EFI system partition on a Master Boot Record partition table is identified by the partition type ID .

Choose one of the following methods to create an ESP for a MBR partitioned disk:

  • fdisk: Create a primary partition with partition type EFI (FAT-12/16/32).
  • GNU Parted: Create a primary partition with 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.9, 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", it is recommended to use FAT32. Use the utility from :

# mkfs.fat -F 32 /dev/sdxY

If you get the message , reduce cluster size with mkfs.fat -s2 -F32 ... or ; otherwise the partition may be unreadable by UEFI. See 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.

Typical mount points

The simplest scenarios for mounting the EFI system partition are:

  • mount ESP to . This is the most straightforward method.
    • This facilitates system maintenance, as 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.
  • mount ESP to .
    • 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 (typically /boot).
    • 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.
  • mount ESP to and additionally mount an "Extended Boot Loader Partition" (XBOOTLDR) to . 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 simple methods from #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 , you can mount a directory of the ESP to using a bind mount (see ). This allows pacman to update the kernel directly while keeping the ESP organized to your liking.

Just like in #Alternative mount points, copy all boot files to a directory on your ESP, but mount the ESP outside . Then bind mount the directory:

# mount --bind esp/EFI/arch /boot

After verifying success, edit your Fstab to make the changes persistent:

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 . The file watched for changes is 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

Then enable and start efistub-update.path.

Using filesystem events

Filesystem events can be used to run a script syncing the EFISTUB Kernel after kernel updates. An example with incron follows.

In order to use this method, enable the .

Using mkinitcpio hook

Mkinitcpio can generate a hook that does not need a system level daemon to function. It spawns a background process which waits for the generation of , , and before copying the files.

Add to the list of hooks in /etc/mkinitcpio.conf.

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 above mkinitcpio hook

Edit the file /etc/mkinitcpio.d/linux.preset:

To test that, just run:

# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
# mkinitcpio -p linux

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.

The second file is the script itself. Create the file and make it executable:

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 and for details and UEFI booting and RAID1 for an in-depth guide with a solution.

The key part is to use 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

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.

gollark: Oh, microseconds of tick time.
gollark: What's a "micro-s/t"?
gollark: They were hit by the Rebels' brainwashing rays and converted to the Rebellion.
gollark: Well, I have more metals than that.
gollark: I thought it was two.

See also
This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.