EFI system partition: Difference between revisions

From ArchWiki
m (→‎Using mkinitcpio hook: fix previous edit : all official mkinitcpio hooks use bash, let's keep this the same)
(Undo revision 800115 by Mpan (talk) - partition order is out of scope, Partitioning#Example layouts already shows the suggester order (swap partition after the ESP))
Tag: Undo
 
(81 intermediate revisions by 15 users not shown)
Line 10: Line 10:
{{Related|Boot loader}}
{{Related|Boot loader}}
{{Related articles end}}
{{Related articles end}}
The [[Wikipedia:EFI system partition|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.  
The [[Wikipedia:EFI system partition|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 ==
== Check for an existing partition ==
Line 39: Line 39:
The partition size should provide adequate space for storing boot loaders and other files required for booting.
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[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules][https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-partition-can-be/1310938] 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.[https://www.rodsbooks.com/efi-bootloaders/principles.html] 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.
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.[https://www.rodsbooks.com/efi-bootloaders/principles.html]
* If you plan to mount the partition to [[Partitioning#/boot|/boot]] and will not install more than one kernel, then 400 MiB will be sufficient.
* When [[Dual boot with Windows|dual booting with Windows]], the size should be at least 300 MiB for drives with a 4096 logical sector size ([[Advanced Format]] 4Kn drives)[https://superuser.com/questions/1310927/what-is-the-absolute-minimum-size-a-uefi-partition-can-be/1310938] or at least 100 MiB otherwise.[https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules]
* 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.[https://superuser.com/a/1717643]
* 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 ===
=== GPT partitioned disks ===
Line 47: Line 56:
'''Choose one''' of the following methods to create an ESP for a GPT partitioned disk:
'''Choose one''' of the following methods to create an ESP for a GPT partitioned disk:


* [[fdisk]]: Create a partition with partition type {{ic|EFI System}}.
* [[fdisk]]: Create a partition and use the {{ic|t}} command to [[fdisk#Change partition type|change its partition type]] to {{ic|EFI System}}.
* [[gdisk]]: Create a partition with partition type {{ic|EF00}}.
* [[gdisk]]: Create a partition with partition type {{ic|EF00}}.
* [[GNU Parted]]: Create a partition with {{ic|fat32}} as the file system type and set the {{ic|esp}} flag on it.
* [[GNU Parted]]: Create a partition with {{ic|fat32}} as the file system type and set the {{ic|esp}} flag on it.
Line 55: Line 64:
=== MBR partitioned disks ===
=== MBR partitioned disks ===


{{Note|
{{Warning|It is highly recommended to use GPT instead of MBR.
* It is recommended to use [[GPT]] since some firmwares might not support UEFI/MBR booting due to it not being supported by [[Dual boot with Windows|Windows Setup]].
 
* Some firmware might not support UEFI/MBR booting due to it not being supported by [[Dual boot with Windows|Windows Setup]].
* ''bootctl'' does not support installing [[systemd-boot]] to an MBR partitioned disk; see [https://github.com/systemd/systemd/issues/1125 systemd issue 1125].
* ''bootctl'' does not support installing [[systemd-boot]] to an MBR partitioned disk; see [https://github.com/systemd/systemd/issues/1125 systemd issue 1125].


See also [[Partitioning#Choosing between GPT and MBR]] for the advantages of GPT in general.
See also [[Partitioning#Choosing between GPT and MBR]] for the limits of MBR and the advantages of GPT in general.
}}
}}


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


* [[fdisk]]: Create a primary partition with partition type {{ic|EFI (FAT-12/16/32)}}.
* [[fdisk]]: Create a primary partition and and use the {{ic|t}} command to [[fdisk#Change partition type|change its partition type]] to {{ic|EFI (FAT-12/16/32)}}.
* [[GNU Parted]]: Create a primary partition with {{ic|fat32}} as the file system type and set the {{ic|esp}} flag on it.
* [[GNU Parted]]: Create a primary partition with {{ic|fat32}} as the file system type and set the {{ic|esp}} flag on it.


Line 73: Line 83:
== Format the partition ==
== Format the partition ==


The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see [https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf#G17.1019485 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 [[Mac]]s supports the HFS+ file system.
The UEFI specification mandates support for the FAT12, FAT16, and FAT32 file systems (see [https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format-1 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 [[Mac]]s 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"[https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf#G17.1345080], it is recommended to use [[FAT32]]. Use the {{man|8|mkfs.fat}} utility from {{Pkg|dosfstools}}:
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"[https://uefi.org/specs/UEFI/2.10/13_Protocols_Media_Access.html#file-system-format], it is recommended to use [[FAT32]]. Use the {{man|8|mkfs.fat}} utility from {{Pkg|dosfstools}}:


  # mkfs.fat -F 32 /dev/sd''xY''
  # mkfs.fat -F 32 /dev/sd''xY''


If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}}, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}; otherwise the partition may be unreadable by UEFI. See {{man|8|mkfs.fat}} for supported cluster sizes.
If you get the message {{ic|WARNING: Not enough clusters for a 32 bit FAT!}} and you cannot [[#Create the partition|create]] a larger ESP, reduce cluster size with {{ic|mkfs.fat -s2 -F32 ...}} or {{ic|-s1}}; otherwise the partition may be unreadable by UEFI. See {{man|8|mkfs.fat}} 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:
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:
Line 88: Line 98:


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.
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 {{ic|/boot}}, make sure to not rely on the [[fstab#Automount with systemd|systemd automount mechanism]] (including that of [[systemd#GPT partition automounting|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 [[Kernel module#systemd|preload the required kernel modules on boot]], e.g.:
{{hc|/etc/modules-load.d/vfat.conf|
vfat
nls_cp437
nls_ascii
}}
}}


=== Typical mount points ===
=== Typical mount points ===


The simplest scenarios for mounting EFI system partition are:
The three typical scenarios for mounting the EFI system partition are:


* [[mount]] ESP to {{ic|/efi}} and use a [[boot loader]] which is capable of accessing the kernel(s) and initramfs image(s) that are stored elsewhere (typically [[Partitioning#/boot|/boot]]). See [[Arch boot process#Boot loader]] for more information on boot loader requirements and capabilities.
* [[mount]] the ESP to {{ic|/boot}}:
* [[mount]] ESP to {{ic|/boot}}. This is the preferred method when directly booting an [[EFISTUB]] kernel from UEFI or booting it via a boot manager like [[systemd-boot]].
** This facilitates system maintenance and administration, as {{ic|/boot}} is the default path where [[microcode]] packages place the CPU microcode initramfs files and where [[mkinitcpio]] places [[kernel]]s and [[initramfs]] images.
* [[mount]] ESP to {{ic|/efi}} and additionally mount an "Extended Boot Loader Partition" (XBOOTLDR) to {{ic|/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#Installation using XBOOTLDR|systemd-boot]].
** This ensures that the above files are accessible to most [[boot loader]]s, 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 {{ic|/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 [[GRUB#Encrypted /boot|encrypting /boot]] impossible, as EFI-related files have to be accessible by the firmware.
* [[mount]] the ESP to {{ic|/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 {{ic|/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 {{ic|/boot}}, avoiding FAT limitations.
** It allows to mount separately the ESP according to the need, ''e.g.'' only when upgrading the [[bootloader]].
** If using [[dm-crypt/Encrypting an entire system|system encryption]] with the appropriate setup, it allows to leave only a few required files unencrypted while {{ic|/boot}} remains protected: this can be useful for [[unified kernel image]]s or [[boot loader]]s that have file system drivers capable of accessing the kernel(s) and files that are stored elsewhere.
* [[mount]] the ESP to {{ic|/efi}} and additionally mount an "Extended Boot Loader Partition" (XBOOTLDR) to {{ic|/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#Installation using XBOOTLDR|systemd-boot]].


{{Tip|
{{Note|
* {{ic|/efi}} is a replacement[https://github.com/systemd/systemd/pull/3757#issuecomment-234290236] for the previously popular (and possibly still used by other Linux distributions) ESP mountpoint {{ic|/boot/efi}}.
* {{ic|/efi}} is a replacement[https://github.com/systemd/systemd/pull/3757#issuecomment-234290236] for the historical and now discouraged ESP mountpoint {{ic|/boot/efi}}.
* The {{ic|/efi}} directory is not available by default, you will need to first create it with {{man|1|mkdir}} before mounting the ESP to it.
* The {{ic|/efi}} directory is not available by default, you will need to first [[create]] it before mounting the ESP to it.
}}
}}


=== Alternative mount points ===
=== 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 {{ic|''esp''}}).
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 {{ic|''esp''}}).


  # mkdir -p ''esp''/EFI/arch
  # mkdir -p ''esp''/EFI/arch
Line 114: Line 147:


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.
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.
{{Note|If ESP is not mounted to {{ic|/boot}}, make sure to not rely on the [[fstab#Automount with systemd|systemd automount mechanism]] (including that of {{man|8|systemd-gpt-auto-generator}}). Always have it mounted 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 ESP.
Alternatively [[Kernel module#Automatic module loading with systemd|preload the required kernel modules on boot]], e.g.:
{{hc|/etc/modules-load.d/vfat.conf|
vfat
nls_cp437
nls_ascii
}}
}}


==== Using bind mount ====
==== Using bind mount ====
Line 131: Line 152:
Instead of mounting the ESP itself to {{ic|/boot}}, you can mount a directory of the ESP to {{ic|/boot}} using a bind [[mount]] (see {{man|8|mount}}). This allows [[pacman]] to update the kernel directly while keeping the ESP organized to your liking.
Instead of mounting the ESP itself to {{ic|/boot}}, you can mount a directory of the ESP to {{ic|/boot}} using a bind [[mount]] (see {{man|8|mount}}). This allows [[pacman]] to update the kernel directly while keeping the ESP organized to your liking.


{{Note|1=This requires a [[FAT#Kernel configuration|kernel]] and [[bootloader]] 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 {{ic|/boot/}}). See the forum post [https://bbs.archlinux.org/viewtopic.php?pid=1331867#p1331867].}}
{{Note|1=This requires a [[FAT#Kernel configuration|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 {{ic|/boot/}}). See the forum post [https://bbs.archlinux.org/viewtopic.php?pid=1331867#p1331867].}}


Just like in [[#Alternative mount points]], copy all boot files to a directory on your ESP, but mount the ESP '''outside''' {{ic|/boot}}. Then bind mount the directory:
Just like in [[#Alternative mount points]], copy all boot files to a directory on your ESP, but mount the ESP '''outside''' {{ic|/boot}}. Then bind mount the directory:
Line 243: Line 264:
# mkinitcpio preset file for the 'linux' package
# mkinitcpio preset file for the 'linux' package


# Directory to copy the kernel, the initramfs...
# Directory to install the kernel, the initramfs...
ESP_DIR="''esp''/EFI/arch"
ESP_DIR="''esp''/EFI/arch"


ALL_config="/etc/mkinitcpio.conf"
#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
ALL_kver="${ESP_DIR}/vmlinuz-linux"
cp -af /boot/vmlinuz-linux "${ESP_DIR}/"
<nowiki>[[ -e /boot/intel-ucode.img ]] && cp -af /boot/intel-ucode.img "${ESP_DIR}/"
<nowiki>[[ -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}/"</nowiki>
[[ -e /boot/amd-ucode.img ]] && cp -af /boot/amd-ucode.img "${ESP_DIR}/"</nowiki>
Line 265: Line 285:


  # rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
  # rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img
# mv /boot/vmlinuz-linux ''esp''/EFI/arch/
  # mkinitcpio -p linux
  # mkinitcpio -p linux


Line 271: Line 292:
{{hc|/etc/mkinitcpio.d/linux.preset|2=
{{hc|/etc/mkinitcpio.d/linux.preset|2=
ESP_DIR="''esp''/EFI/arch"
ESP_DIR="''esp''/EFI/arch"
cp -f "/boot/vmlinuz-linux$suffix" "$ESP_DIR/"
#ALL_config="/etc/mkinitcpio.conf"
ALL_config="/etc/mkinitcpio.conf"
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
ALL_kver="$ESP_DIR/vmlinuz-linux$suffix"
PRESETS=('default')
PRESETS=('default')
Line 350: Line 370:


* [https://blog.uncooperative.org/uefi/linux/shim/efi%20system%20partition/2014/02/06/the-efi-system-partition.html The EFI system partition and the default boot behavior]
* [https://blog.uncooperative.org/uefi/linux/shim/efi%20system%20partition/2014/02/06/the-efi-system-partition.html The EFI system partition and the default boot behavior]
* [https://ramsdenj.com/2016/04/15/multi-boot-linux-with-one-boot-partition.html Multi Boot Linux With One Boot Partition | John Ramsden]
* [https://ramsdenj.com/posts/2016-04-15-multi-boot-linux-with-one-boot-partition/ Multi Boot Linux With One Boot Partition | John Ramsden]

Latest revision as of 08:13, 11 February 2024

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

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] 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: You may also need to copy the Microcode 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 [7].

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 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 vmlinuz, initramfs-linux.img, and initramfs-linux-fallback.img before copying the files.

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

/etc/initcpio/install/efistub-update
#!/usr/bin/env bash
build() {
	/usr/local/bin/efistub-copy $$ &
}

help() {
	cat <<HELPEOF
This hook waits for mkinitcpio to finish and copies the finished ramdisk and kernel to the ESP
HELPEOF
}
/usr/local/bin/efistub-copy
#!/bin/sh

if [ "$1" -gt 0 ]
then
	while [ -e /proc/"$1" ]
	do
		sleep .5
	done
fi

rsync -a /boot/ esp/

echo "Synced /boot with ESP"

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:

/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"
[[ -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}/"

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

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 [8] and [9] 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

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.

See also