EFI 系统分区
EFI 系统分区（也称为 ESP）是一个独立于操作系统的分区，作为由 UEFI 固件启动的 UEFI 引导加载程序、应用程序和驱动程序的存储位置。它是 UEFI 启动的必要条件。
检查现有分区
如果你正在一台装有操作系统（例如 Windows 10）的 UEFI 兼容计算机上安装 Arch Linux，那么你很可能已经拥有一个 EFI 系统分区。
要查明磁盘分区方案和系统分区，请以 root 身份对要从中启动的磁盘使用 fdisk：
# fdisk -l /dev/sdx
该命令会返回：
- 磁盘的分区表：如果分区表是 GPT，则显示
Disklabel type: gpt；如果是 MBR，则显示Disklabel type: dos。 - 磁盘上的分区列表：在列表中查找 EFI 系统分区，它通常至少有 100 MiB 大小，且类型为
EFI System或EFI (FAT-12/16/32)。为了确认这就是 ESP，将其 挂载 并检查是否包含名为EFI的目录，如果有，则肯定是 ESP。
如果你找到了一个可用的现有 EFI 系统分区，只需直接前往 #挂载分区。如果没有找到，则需要创建一个，请前往 #创建分区。
创建分区
以下两节展示了如何创建 EFI 系统分区 (ESP)。
分区大小应提供足够的空间来存储引导加载程序及启动所需的其他文件。
建议将该分区设置为 1 GiB，以确保有足够的空间容纳多个内核或统一内核映像、引导加载程序、固件更新文件以及任何其他操作系统或 OEM 文件。如有疑问，4 GiB 对任何人来说都绰绰有余。
对于像 支持 Btrfs 的 Snapper 快照集成引导加载程序 (Limine)（支持创建多个可引导快照）和 ESP 上的 Archiso（用于系统恢复的无需外部媒介的可引导 ISO 映像）等工具，请考虑更大的空间（例如 8 GiB）。
- 对于早期和/或有缺陷的 UEFI 实现，可能需要至少 512 MiB 的空间。[1]
- 如果你计划将该分区挂载到 /boot 且不会安装多个内核，那么 400 MiB 就足够了。
- 当与 Windows 双启动时，对于逻辑扇区大小为 4096 字节的驱动器（高级格式化 4Kn 驱动器），大小应至少为 300 MiB[2]，否则至少需要 100 MiB[3]。
- 为确保该分区能被格式化为 FAT32，在逻辑扇区大小为 512 字节的驱动器上应至少为 36 MiB，在逻辑扇区大小为 4096 字节的驱动器上应至少为 260 MiB。[4]
- 如果上述情况均不适用，分区大小最小可以为 2 MiB，在这种情况下它只能容纳引导加载程序。
GPT 分区磁盘
GUID 分区表上的 EFI 系统分区通过 分区类型 GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B 进行标识。
选择一种以下方法为 GPT 分区磁盘创建 ESP：
- fdisk：创建一个分区，然后使用
t命令通过别名uefi将其 分区类型更改 为EFI System。 - gdisk：创建一个分区类型为
EF00的分区。 - GNU Parted：创建一个文件系统类型为
fat32的分区，并设置其esp标志。
创建分区后，应使用文件系统对其进行格式化。请继续阅读下方的 #格式化分区 一节。
MBR 分区磁盘
- 某些固件可能不支持 UEFI/MBR 启动，因为 Windows 安装程序不支持它。
- bootctl 不支持将 systemd-boot 安装到 MBR 分区磁盘；详见 systemd 问题 1125。
有关 MBR 的限制以及 GPT 的总体优势，请参阅 分区#在 GPT 和 MBR 之间选择。
主引导记录分区表上的 EFI 系统分区通过 分区类型 ID EF 进行标识。
选择一种以下方法为 MBR 分区磁盘创建 ESP：
- fdisk：创建一个主分区，然后使用
t命令将其 分区类型更改 为EFI (FAT-12/16/32)。 - GNU Parted：创建一个主分区，文件系统类型设置为
fat32，并设置其esp标志。
创建分区后，应使用文件系统对其进行格式化。请继续阅读下方的 #格式化分区 一节。
格式化分区
UEFI 规范要求支持 FAT12、FAT16 和 FAT32 文件系统（详见 UEFI 规范版本 2.11，第 13.3.1.1 节），但任何合规厂商都可以选择添加对其他文件系统的支持；例如，苹果 Mac 上的固件支持 HFS+ 文件系统。
为了防止与其他操作系统产生潜在问题，且鉴于 UEFI 规范指出 UEFI“包含将 FAT32 用于系统分区，将 FAT12 或 FAT16 用于可移动媒体的使用”[5]，建议使用 FAT32。请使用 dosfstools 软件包中的 mkfs.fat(8) 工具：
# mkfs.fat -F 32 /dev/sdxY
如果你收到消息 WARNING: Number of clusters for 32 bit FAT is less than suggested minimum. 且无法 创建 更大的 ESP，请使用 mkfs.fat -s 2 -F 32 ... 或 -s 1 减小簇大小；否则分区可能无法被 UEFI 读取。支持的簇大小请参阅 mkfs.fat(8)。
对于小于 32 MiB 的分区，使用 FAT32 可能不可行。在这种情况下，请将其格式化为 FAT16 或 FAT12。例如，一个 2 MiB 的 ESP 只能支持 FAT12。
# mkfs.fat -F 12 /dev/sdxY
挂载分区
内核、initramfs 文件以及（在大多数情况下）处理器的 微码 (microcode) 需要能够被 引导加载程序 或 UEFI 本身访问，才能成功启动系统。因此，如果你想保持设置简单，你的引导加载程序选择将限制 EFI 系统分区的可用挂载点。
/boot，请确保在内核升级期间不要依赖 systemd 自动挂载机制（包括 systemd-gpt-auto-generator 的机制）。在进行任何系统或内核更新之前，务必手动挂载它，否则更新后你可能无法再挂载它，从而导致被锁定在当前运行的内核中，且无法更新 ESP 上的内核副本。或者 在引导时预加载所需的内核模块，例如：
/etc/modules-load.d/vfat.conf
vfat nls_cp437 nls_ascii
典型挂载点
挂载 EFI 系统分区的三个典型场景是：
- 将 ESP 挂载 到
/boot- 这简化了系统维护和管理，因为
/boot是 微码 软件包放置 CPU 微码 initramfs 文件以及 mkinitcpio 放置 内核 和 initramfs 映像的默认路径。 - 这确保了上述文件可被大多数 引导加载程序 访问，因为并非所有引导加载程序都能访问其他卷上的文件。
- 这阻止了设置文件特定的 权限 和/或 扩展属性，因为 FAT 在挂载时设置全局权限。
- 这增加了 ESP 的空间需求，因为通常安装在
/boot中的文件将与用于 UEFI 启动的文件合并在一起。 - 这使内核和 initramfs 映像暴露在来自可引导驱动器或其他操作系统的潜在危险操作中（在双系统环境下）。
- 这使得 加密 /boot 变得不可能，因为引导加载程序及其文件必须能被固件访问。
- 这使得根卷快照（使用 Btrfs, Bcachefs, ZFS, LVM）的效果降低，因为
/boot内容不会被包含在内。在内核更新的情况下，恢复到旧内核版本的快照会导致系统无法启动，并需要使用外部媒体手动 降级内核。
- 这简化了系统维护和管理，因为
- 将 ESP 挂载 到
/efi，并额外将一个“扩展引导加载程序分区”(XBOOTLDR) 挂载到/boot。这在之前创建的 ESP 太小无法容纳多个引导加载程序和/或内核，且 ESP 又无法轻易调整大小时（例如在 Windows 之后安装 Linux 进行 双启动 时）非常有用。此方法至少得到 systemd-boot 的支持。 - 将 ESP 挂载 到
/efi- 它确保了操作系统文件与 UEFI 文件之间的关注点分离，UEFI 分区可能包含其他不应被干扰的操作系统文件。
- 它避免了增加 ESP 的空间需求，因为不会将安装到
/boot的文件放置其中：只有 EFI 二进制文件（引导加载程序（及可选的驱动程序）和/或统一内核映像）会存储在 ESP 上，从而节省了存储空间。 - 它允许保留
/boot中文件的 Linux 特有文件系统权限，避免了 FAT 的限制。 - 它允许根据需要分别挂载 ESP，例如仅在升级 引导加载程序 时挂载。
- 如果使用 系统加密 并进行适当配置，它允许仅保留少数必要文件不加密，而
/boot保持受保护状态：这对于 统一内核映像 或拥有能够访问存储在其他位置的内核及文件的文件系统驱动程序的 引导加载程序 很有用。
替代挂载点
如果你不使用其中一个 #典型挂载点，则需要将启动文件复制到 ESP（下文统称为 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/
此外，你还需要在后续内核更新时保持 ESP 上的文件为最新。否则可能会导致系统无法启动。以下各节讨论了自动化此过程的几种机制。
使用绑定挂载 (bind mount)
与其将 ESP 本身挂载到 /boot，不如使用绑定 挂载 将 ESP 的目录挂载到 /boot（参见 mount(8)）。这允许 pacman 直接更新内核，同时保持 ESP 按你喜欢的方式组织。
/boot/ 中建立符号链接的发行版）可能会有问题。参见论坛帖子 [8]。就像在 #替代挂载点 中一样，将所有启动文件复制到 ESP 上的一个目录中，但要将 ESP 挂载到 /boot 外部。然后执行绑定挂载。
# mount --bind esp/EFI/arch /boot
验证成功后，编辑你的 Fstab 以使更改持久化。
/etc/fstab
esp/EFI/arch /boot none defaults,bind 0 0
使用 systemd
systemd 具有事件触发任务功能。在这种特定情况下，使用路径更改检测能力在 EFISTUB 内核和 initramfs 文件在 /boot/ 中更新时同步它们。被监视更改的文件是 initramfs-linux-fallback.img，因为这是 mkinitcpio 构建的最后一个文件，以确保在开始复制之前所有文件都已构建完毕。需要创建的 systemd 路径和单元文件如下：
/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/
然后 启用 并 启动 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
使用文件系统事件
文件系统事件可用于在内核更新后运行脚本来同步 EFISTUB 内核。下面是一个使用 incron 的示例。
/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 是要监视的文件。第二个参数 IN_CLOSE_WRITE 是要监视的操作。第三个参数 /usr/local/bin/efistub-update 是要执行的脚本。/etc/incron.d/efistub-update.conf
/boot/initramfs-linux-fallback.img IN_CLOSE_WRITE /usr/local/bin/efistub-update
为了使用此方法，请 启用 incrond.service。
使用 mkinitcpio 预设
由于 /etc/mkinitcpio.d/ 中的预设支持 shell 脚本，因此只需编辑预设即可复制内核和 initramfs。
替换 mkinitcpio 钩子
编辑文件 /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"
要测试它，只需运行：
# rm /boot/initramfs-linux-fallback.img /boot/initramfs-linux.img # mv /boot/vmlinuz-linux esp/EFI/arch/ # mkinitcpio -p linux
另一个示例
/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
使用 mkinitcpio 后置钩子
mkinitcpio 后置钩子可用于在 initramfs 生成后将内核和 initramfs 映像复制到所需目录。
/etc/initcpio/post/copy-kernel-and-initramfs
#!/usr/bin/env bash
kernel="$1"
initramfs="$2"
target_dir="esp/EFI/arch"
files_to_copy=()
for file in "$kernel" "$initramfs"; 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}/"
使用 pacman 钩子
最后一个选项依赖于在事务结束时运行的 pacman 钩子。
第一个文件是一个钩子，它监视相关文件，如果它们在之前的事务中被修改，则会运行它。
/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
第二个文件是脚本本身。创建该文件并使其 可执行。
/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
技巧与提示
将分区替换为更大的分区
在预装操作系统的磁盘上，EFI 系统分区可能小于 #创建分区 中建议的大小。例如，Windows 安装程序会在非 4Kn 驱动器上创建一个仅 100 MiB 的 EFI 系统分区。
在这种情况下，创建一个新的、更大的 EFI 系统分区以防止空间不足是一个好主意。
在 Windows 中释放空间以创建新分区
在 Windows 中，分区可以通过“磁盘管理”工具 (diskmgmt.msc) 以图形化方式管理，也可以通过 diskpart.exe 命令行工具管理。
以管理员身份运行 diskmgmt.msc。
- 右键单击“(C:)”分区（默认 Windows 创建的分区中唯一可以联机调整大小的分区），然后选择 压缩卷...。
- 输入
4096作为要压缩的空间量，然后单击 压缩。
“(C:)”分区后面现在应该有 4 GiB 的未分配空间。
启动到 Arch Linux 或 Arch Linux 安装媒介，继续创建新分区。
删除旧分区并创建新分区
首先，确保备份 EFI 系统分区的内容。例如，假设 esp 是其挂载点：
# cp -a esp /esp_backup
卸载 EFI 系统分区：
# umount esp
运行 blkid 并记下 UUID 和 PARTUUID 值。稍后将把它们复用到新分区上。
# blkid
/dev/sdxY: UUID="XXXX-XXXX" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY"
# sgdisk --delete=Y /dev/sdx
在最大的未分配空间中创建一个新分区，同时重用旧的 PARTUUID 和 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
告诉内核使用 parted 中的 partprobe(8) 重新读取分区表：
# partprobe /dev/sdx
通过使用 fdisk 列出分区，确认已创建大小为 4 GiB 的新 EFI 系统分区：
# 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.
删除和创建分区时分区号不会重新排序，因此磁盘上的 EFI 系统分区编号很可能与之前相同。
将分区格式化为 FAT32，并重用旧的 UUID（同时移除其中的连字符）：
# mkfs.fat -F 32 -i XXXXXXXX /dev/sdxY
最后，挂载新分区并从备份中恢复其内容：
# mount /dev/sdxY esp # cp -a /esp_backup/. esp/
如果你之前停止了 esp.automount，请再次 启动 它。
牺牲相邻的交换分区以扩大 ESP
如果 EFI 系统分区后面紧邻一个交换分区，你可以牺牲它来为扩大 EFI 系统分区提供空间。例如，布局类似于：
# 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)
首先，停用交换分区并将其从 fstab 中移除。
使用 fdisk 删除交换分区并扩大 EFI 系统分区。
- 运行
# fdisk /dev/sdx
- 使用
d命令删除交换分区（在上述示例布局中为分区号2）。 - 使用
e命令扩大 EFI 系统分区（在上述示例布局中为分区号1）。对新大小使用建议的默认值，然后按Enter。 - 使用
w命令将更改写入磁盘并退出。
分区调整大小后，你需要调整其中的文件系统。由于 fatresize(1) 无法工作 且 libparted 无法调整特定大小的 FAT 卷，唯一的选择是备份现有文件系统中的文件，并创建一个占用分区所有空间的新文件系统。
记下文件系统 UUID，以便为新文件系统重用它。
$ lsblk -dno UUID /dev/sdxY
XXXX-XXXX
备份 EFI 系统分区的内容。例如，假设 esp 是其挂载点：
# cp -a esp /esp_backup
卸载 EFI 系统分区：
# umount esp
擦除分区上的文件系统签名，以避免旧文件系统产生任何干扰：
# wipefs -af /dev/sdxY
将分区格式化为 FAT32，并重用旧的 UUID（同时移除其中的连字符）：
# mkfs.fat -F 32 -i XXXXXXXX /dev/sdxY
最后，挂载新分区并从备份中恢复其内容：
# mount /dev/sdxY esp # cp -a /esp_backup/. esp/
如果你之前停止了 esp.automount，请再次 启动 它。
既然交换分区已消失，请在 交换文件 上设置交换空间。
故障排除
位于软件 RAID1 上的 ESP
使 ESP 成为 RAID1 阵列的一部分是可能的，但这样做会带来数据损坏的风险，并且在创建 ESP 时需要考虑更多因素。详见 [9] 和 [10]，有关解决方案的深入指南请参见 UEFI 启动和 RAID1。
关键部分是使用 --metadata 1.0 以将 RAID 元数据保留在分区的末尾，否则固件将无法访问它。
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sdaX /dev/sdbY
或者，由于 ESP 不常更新，可以通过在相关更新期间将主 ESP 复制到不同磁盘上的次要 ESP 来管理。然后可以使用 efibootmgr 手动为次要 ESP 添加引导条目。参见 Debian:UEFI#RAID for the EFI System Partition 的实现示例。请注意，虽然这避免了 RAID 方法的一些风险，但它仅在仅使用单个操作系统时有效。
固件无法识别 EFI 目录
如果你为 FAT 文件系统提供了 卷名（即文件系统标签），请务必将其命名为非 EFI 的名称。这可能会触发某些固件中的错误（由于卷名与 EFI 目录名匹配），从而导致固件认为 EFI 目录不存在。
休眠和多系统引导
如果你运行的是多启动系统（包括但不限于 Windows 双启动），并且希望在主 Arch Linux 休眠时能够启动到另一个系统，你必须格外小心，不要在两个系统中同时挂载 ESP，因为这很可能会导致数据损坏和使用时的 I/O 错误。
有三种可能的缓解策略：
- 每个系统使用独立的 EFI 系统分区。只要 ESP 位于物理上不同的磁盘上，大多数 UEFI 都支持这一点，但硬件支持和易用性可能会有所不同。
- 使用 systemd 的自动挂载机制 仅在需要时挂载 ESP。请确保同时指定空闲超时（
x-systemd.idle-timeout=选项），否则 systemd 不会在使用后卸载 ESP。但是，请注意两个限制：首先，除非你将 ESP 挂载到/boot，否则在内核升级期间不要依赖自动挂载（参见 上面的注释）。其次，你必须确保在系统使用后自动卸载 ESP 之前，不要让系统休眠（参见 自动卸载）。 - 将 ESP 挂载到
/efi，并在系统休眠前卸载，恢复后重新挂载。参见 下方的说明。
通过成功应用上述策略之一，你可以休眠此系统，但不能休眠其他系统，除非你也为它们应用了缓解策略之一。例如，对你的主 Arch Linux 应用其中一个解决方案，允许你休眠 Arch Linux 并启动到另一个系统（如 Ubuntu Linux），但不能休眠该 Ubuntu Linux 并启动回你的主 Arch Linux。要在 Windows 下允许此操作，需要独立的 EFI 系统分区。
严格来说，这种一次多次挂载同一文件系统的问题既不限于 EFI 系统分区，也不限于系统休眠。然而，对于 ESP 来说它特别重要，因为 ESP 需要在多个系统之间共享。这些缓解策略也可以适用于其他用例。
休眠时卸载并重新挂载 ESP
如果你选择上面的选项 3，你可以创建并 启用 以下 systemd 系统服务，它会在系统休眠前卸载 ESP，并在恢复后重新挂载它：
/etc/systemd/system/efi-remount-on-hibernate.service
[Unit] Description=Unmount and remount EFI system partition on hibernation Before=hibernate.target hybrid-sleep.target suspend-then-hibernate.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecCondition=/usr/bin/systemctl is-active --quiet efi.mount ExecStart=/usr/bin/systemctl stop efi.mount ExecStop=/usr/bin/systemctl start efi.mount [Install] WantedBy=hibernate.target hybrid-sleep.target suspend-then-hibernate.target
然而，由于 efi.mount 默认被作为 local-fs.target 的依赖被拉入，停止 efi.mount 也会永久关闭 local-fs.target。这可能会产生各种负面副作用，包括关闭系统时的排序问题，这可能会触发 systemd 将 efi.mount 自动标记为有缺陷。通过告知 systemd efi.mount 不是 local-fs.target 所必需的，而只是所需的，可以缓解这种情况。为确保这一点，你必须在 /etc/fstab 中将以下挂载选项添加到 /efi：
x-systemd.wanted-by=local-fs.target,x-systemd.after=local-fs-pre.target,x-systemd.before=local-fs.target