windows / Linux | EFI 系统分区详解

EFI 系统分区详解

1. 概述

1.1 定义与本质

EFI 系统分区（EFI System Partition，ESP）是由 UEFI 规范定义的一种独立于操作系统的分区，用于存储 UEFI 固件启动所需的引导加载程序、应用程序及驱动程序。该分区是 UEFI 启动机制的必要组成部分。

从规范角度而言，ESP 的本质特征并非源于其物理位置或分区序号，而是取决于固件是否将其识别为启动目标。一个分区被视作 ESP 的充要条件为：

1. 磁盘采用 GUID 分区表（GUID Partition Table，GPT），且该分区的类型 GUID 为C12A7328-F81F-11D2-BA4B-00A0C93EC93B（gdisk 类型码EF00，fdisk 别名uefi）。
2. 文件系统为 UEFI 规范所支持的 FAT 变体（FAT12、FAT16 或 FAT32）。
3. 固件在启动过程中主动扫描并识别该分区。

因此，ESP 并非因其 GPT GUID 或标签而 inherently 特殊，这些属性仅是固件在需要定位启动介质时使用的识别凭证。即便在磁盘上创建多个具有 ESP GUID 的分区，固件亦无义务扫描全部候选分区，且不对选择哪一个作出保证。

1.2 规范要求与文件系统

UEFI 规范要求固件必须支持 FAT12、FAT16 和 FAT32 文件系统。尽管合规厂商可扩展支持其他文件系统（例如 Apple Mac 固件对 HFS+ 的支持），但为保证跨平台兼容性，ESP 应格式化为 FAT32。对于容量小于 32 MiB 的分区，可采用 FAT16 或 FAT12；例如，2 MiB 的 ESP 仅支持 FAT12。

格式化应使用mkfs.fat（源自 dosfstools 软件包）。若收到警告WARNING: Number of clusters for 32 bit FAT is less than suggested minimum，且无法扩大分区时，可通过-s 2或-s 1减小簇大小，否则分区可能无法被某些 UEFI 实现读取。

1.3 容量规划

建议将 ESP 容量设置为 1 GiB，以确保容纳多个内核、统一内核映像（Unified Kernel Image）、引导加载程序、固件更新文件及其他操作系统或 OEM 文件。若存在疑虑，4 GiB 足以覆盖绝大多数场景。特定用例如下：

为确保可格式化为 FAT32，在 512 B 扇区磁盘上应至少为 36 MiB，在 4 KiB 扇区磁盘上应至少为 260 MiB。若上述情形均不适用，分区最小可为 2 MiB，但此时仅能容纳引导加载程序本身。

2. 启动机制

2.1 UEFI 启动变量

在正常运行条件下，系统启动时固件首先检索 NVRAM 中的BootOrder变量。该变量为一个 16 位无符号整数列表，以十六进制大写形式表示，例如：

BootOrder: 0001, 001A, 0003

固件按序迭代该列表。对于每个条目（如0001），固件查找同名的Boot####变量（如Boot0001）。若变量存在，则读取其内容；若不存在，则继续处理下一项。

Boot####变量的内容通常包含：

• 一个人类可读的标签（Label）；
• 一条设备路径（Device Path），用于描述定位启动目标所需的硬件拓扑与逻辑位置；
• 可选的启动参数，传递给被加载的程序。

2.2 设备路径

设备路径（Device Path）是一个序列化的节点链，每个节点对应系统拓扑中的一个层级。典型的设备路径示例如下：

ACPI(a0341d0,0)PCI(1f,2)SATA(0,0,0)HD(1,800,64000,12029cda-8961-470d-82ba-aeb17dba91a5)File(\EFI\fedora\shim.efi)

各节点的含义为：

• ACPI(a0341d0,0)：ACPI 命名空间中的设备，通常对应 PCI Express Root Port；
• PCI(1f,2)：PCI 总线上的设备与功能号；
• SATA(0,0,0)：SATA 控制器端口、端口乘数器及 LUN；
• HD(1,800,64000,12029cda-8961-470d-82ba-aeb17dba91a5)：硬盘分区节点，包含分区号、起始 LBA、大小（以扇区计）及分区 GUID；
• File(\EFI\fedora\shim.efi)：目标文件路径，使用反斜杠作为分隔符（UEFI 环境约定）。

设备路径中的HD()节点所包含的分区 GUID 仅需与分区表中的 GUID 匹配，不要求该 GUID 必须是 ESP 的专用 GUID。换言之，固件通过设备路径定位分区时，并不检验该分区是否为严格意义上的 ESP；唯一的硬性要求是文件系统必须为 FAT，因为这是固件保证能够识别的唯一文件系统。

固件按顺序初始化设备路径中涉及的每个外设。部分设备（如 ACPI 表、PCI Root Hub）通常已提前初始化，而 SATA 控制器及其下游设备则可能需要在此阶段完成初始化。初始化完成后，固件检查磁盘是否存在匹配HD()描述的分区。若找到且包含 FAT 文件系统，则进一步查找File()指定的路径。若任一环节失败，固件转向BootOrder的下一项，重复上述流程。

2.3 正常启动流程

正常启动的完整流程可归纳如下：

1. 固件读取 NVRAM 中的BootOrder；
2. 按序读取每个Boot####变量；
3. 解析变量中的设备路径；
4. 初始化设备路径中尚未就绪的外设；
5. 匹配HD()节点指定的分区；
6. 验证分区文件系统为 FAT；
7. 加载File()节点指定的 EFI 应用程序；
8. 将控制权移交至该应用程序。

若设备路径仅包含HD()与File()节点而未指定完整的总线拓扑，UEFI 规范允许固件以任意顺序初始化所有外设，直至定位到匹配的分区。此种简化路径在常见实现中广泛存在。

2.4 默认启动行为与回退机制

当BootOrder遍历完毕且未找到有效启动项时，固件进入默认启动行为（Default Boot Behavior）。此时固件执行以下步骤：

1. 初始化所有可发现的外设；
2. 优先扫描可移动介质（如光学介质、U 盘）。对每个可移动设备，查找具有 ESP GUID 及 FAT 文件系统的分区，并尝试加载\EFI\BOOT\BOOTX64.EFI（文件名依架构而定，如BOOTIA32.EFI、BOOTAA64.EFI等）。
3. 若无可移动介质可启动，或启动的应用程序返回错误，则继续扫描直至穷尽。
4. 若仍无有效启动源，转而扫描固定介质（如内置硬盘），以相同方式查找 ESP 并尝试启动\EFI\BOOT\BOOTX64.EFI。

此机制使得操作系统安装介质或 Live 镜像无需预写 NVRAM 变量即可启动。对于已安装系统，若 NVRAM 启动项损坏或磁盘被迁移至新机器，该回退路径提供了自动修复的可能性。

2.4.1 fallback.efi 与启动项重建

在采用 shim 的发行版（如 Fedora）中，\EFI\BOOT\BOOTX64.EFI实为 shim 的副本，但其行为因启动路径不同而有所差异。当 shim 检测到自身是从\EFI\BOOT被加载时，会检查同目录下是否存在fallback.efi。若存在，则将其作为普通 UEFI 应用程序执行。

fallback.efi的设计目的在于重建损坏的BootOrder或Boot####变量。其工作流程如下：

1. 查询固件，确定fallback.efi自身所在的磁盘；
2. 遍历该磁盘\EFI目录下除BOOT外的所有子目录；
3. 在每个子目录中查找名为BOOT.CSV的文件；
4. 解析BOOT.CSV（UCS-2 编码的逗号分隔值文件），为每个有效条目创建新的Boot####变量，并将其追加至BootOrder。

以 Fedora 为例，\EFI\fedora\BOOT.CSV的内容格式为：

shim.efi,Fedora,,This is the boot entry for Fedora

fallback.efi将据此创建一个标签为 “Fedora” 的启动项，其设备路径指向该磁盘上的\EFI\fedora\shim.efi。处理完所有 CSV 文件后，fallback.efi启动所添加的第一个选项。下次启动时，BootOrder已恢复，系统将按正常流程启动。

3. 分区创建与格式化

3.1 分区表类型选择

强烈建议使用 GPT 而非 MBR。原因如下：

• 部分固件不支持 UEFI/MBR 启动，且 Windows 安装程序不生成此类配置；
• bootctl（systemd-boot 安装工具）不支持将引导程序安装至 MBR 磁盘；
• GPT 在分区数量、容量及数据完整性方面均优于 MBR。

警告：ESP 必须是磁盘主分区表中的物理分区，不可置于 LVM、软件 RAID（除特定 RAID1 配置外）或其他虚拟化层之上。

3.2 GPT 磁盘上的创建

GPT 磁盘通过分区类型 GUIDC12A7328-F81F-11D2-BA4B-00A0C93EC93B标识 ESP。可选用以下工具之一：

fdisk（util-linux ≥ 2.23）：

fdisk/dev/sdX# n → 新建分区# t → 更改分区类型，输入 uefi

gdisk：

gdisk /dev/sdX# n → 新建分区# Hex code or GUID: EF00

GNU Parted：

parted/dev/sdX# mkpart primary fat32 1MiB 261MiB# set 1 esp on

esp标志在 GPT 磁盘上会自动同时设置boot标志；UEFI 启动仅识别esp，无需单独设置boot。

3.3 MBR 磁盘上的创建

尽管不推荐，MBR 磁盘亦可通过分区类型 ID0xEF（fdisk 中显示为EFI (FAT-12/16/32)）创建 ESP。操作方法：

fdisk：

fdisk/dev/sdX# n → 新建主分区# t → 更改分区类型为 EF

GNU Parted：

parted/dev/sdX# mkpart primary fat32 1MiB 261MiB# set 1 esp on

3.4 文件系统格式化

创建分区后，必须显式格式化。ESP 应格式化为 FAT32：

mkfs.fat-F32/dev/sdXY

对于小于 32 MiB 的分区，若无法使用 FAT32，则降级为 FAT16 或 FAT12：

# 例如 2 MiB 分区mkfs.fat-F12/dev/sdXY

3.5 分区起始对齐

磁盘 LBA 0 至 LBA 33 属于 GPT 元数据保留区域，不可用于用户数据分区：

现代磁盘（尤其是采用 4 KiB 物理块的 SSD 及高级格式化机械硬盘）要求分区起始位置为物理块大小的整数倍，以避免跨块读写导致的性能下降。1 MiB（即 512 B 逻辑扇区下的 LBA 2048，或 4 KiB 逻辑扇区下的 LBA 256）已成为工业标准对齐边界。因此，建议将 ESP 起始位置设为 1 MiB，结束位置按所需容量计算（如 261 MiB 对应实际容量 260 MiB）。

4. 挂载与文件组织

4.1 典型挂载方案

ESP 的挂载点选择直接影响系统维护复杂度与安全性。三种典型方案如下：

方案一：挂载至/boot

• 简化维护：/boot是微码更新工具及mkinitcpio等生成内核映像的默认路径，直接挂载至此可避免手动复制文件。
• 兼容性：确保所有引导加载程序均可访问内核与 initramfs，因为并非所有引导加载程序均支持从其他卷加载文件。
• 缺点：FAT 文件系统不支持文件权限与扩展属性，全局权限在挂载时统一设置；增加 ESP 空间需求；内核与 initramfs 暴露于可引导驱动器或其他操作系统的潜在操作（双系统环境下）；无法加密/boot；根卷快照（Btrfs、ZFS、LVM 等）不包含/boot内容，回滚至旧内核快照可能导致无法启动。

方案二：挂载至/efi，并额外将扩展引导加载程序分区（XBOOTLDR）挂载至/boot

• 适用于 ESP 过小且不易扩容的场景（如 Windows 之后安装 Linux 进行双启动）。
• 至少得到 systemd-boot 支持。
• 保留/boot的 Linux 文件系统特性，同时分离 UEFI 文件与操作系统文件。

方案三：挂载至/efi

• 仅 GRUB 与 rEFInd 支持此方案。
• 实现操作系统文件与 UEFI 文件的完全分离。
• 保留/boot的权限与扩展属性。
• 允许按需单独挂载 ESP。
• 配合系统加密时，可仅保留必要文件不加密，而/boot保持受保护状态。

注：/efi为历史上/boot/efi的替代挂载点。该目录默认不存在，需手动创建。

4.2 多系统共享与目录结构

单个 ESP 可同时服务于多个操作系统。UEFI 固件通过 NVRAM 启动项或\EFI\BOOT\BOOTX64.EFI回退路径选择具体加载的.efi文件。多系统共存的典型目录布局如下：

ESP/ ├── EFI/ │ ├── BOOT/ │ │ └── BOOTX64.EFI # 默认回退引导程序 │ ├── fedora/ │ │ ├── shim.efi │ │ ├── grubx64.efi │ │ └── BOOT.CSV │ ├── arch/ │ │ └── grubx64.efi │ └── Microsoft/ │ └── Boot/ │ └── bootmgfw.efi ├── loader/ # systemd-boot 配置 │ ├── entries/ │ │ ├── arch.conf │ │ └── windows.conf │ └── loader.conf └── installs/ # 多 Linux 内核存放（自定义方案） ├── arch/ │ ├── vmlinuz-linux │ ├── initramfs-linux.img │ └── intel-ucode.img └── tiny/ ├── vmlinuz-linux └── initramfs-linux.img

当使用 systemd-boot 管理多 Linux 安装时，由于各系统的内核与 initramfs 默认均输出至/boot，直接共享一个/boot会导致文件名冲突。解决方案是在 ESP 上为每个系统建立独立子目录（如/mnt/efi/installs/${system-name}），并通过bind mount将其映射到各系统的/boot：

# /etc/fstab/mnt/efi/installs/arch /boot none defaults,bind00

此机制使得各系统的包管理器（如 pacman）可直接更新/boot下的文件，而实际写入位置为 ESP 上的独立子目录。对应的 systemd-boot 条目配置如下：

title Arch Linux linux /installs/arch/vmlinuz-linux initrd /installs/arch/intel-ucode.img initrd /installs/arch/initramfs-linux.img options root=PARTUUID=xxxxx-xxxxx rw

对于无法直接由 systemd-boot 引导的系统（如采用 ZFS 根且需支持 boot environment 的 FreeBSD），可通过链式加载（chainloading）实现：在 systemd-boot 条目中指向 FreeBSD 的boot1.efi，由后者继续完成 FreeBSD 的启动流程。

4.3 内核同步机制

若 ESP 未挂载至/boot，则必须在每次内核或 initramfs 更新后，将文件同步至 ESP。以下列出几种自动化机制：

4.3.1 绑定挂载（Bind Mount）

将 ESP 上的特定子目录绑定挂载至/boot，使包管理器直接更新 ESP 上的文件：

mount--bindesp/EFI/arch /boot

持久化配置（/etc/fstab）：

esp/EFI/arch /boot none defaults,bind 0 0

注意：此方案要求内核与引导加载程序均支持 FAT32。某些发行版若需在/boot中建立符号链接，则可能不兼容。

4.3.2 systemd 路径单元

利用 systemd 的路径检测功能，在/boot/initramfs-linux-fallback.img变更时触发同步服务：

# /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。

4.3.3 mkinitcpio 预设

编辑/etc/mkinitcpio.d/linux.preset，直接指定输出路径至 ESP：

ESP_DIR="esp/EFI/arch"ALL_kver="${ESP_DIR}/vmlinuz-linux"PRESETS=('default''fallback')default_image="${ESP_DIR}/initramfs-linux.img"fallback_image="${ESP_DIR}/initramfs-linux-fallback.img"

4.3.4 mkinitcpio 后置钩子

创建可执行脚本/etc/initcpio/post/copy-kernel-and-initramfs：

#!/usr/bin/env bashkernel="$1"initramfs="$2"target_dir="esp/EFI/arch"files_to_copy=()forfilein"$kernel""$initramfs";doif[[-n"$file"]]&&!cmp-s--"$file""${target_dir}/${file##*/}";thenfiles_to_copy+=("$file")fidone((!${#files_to_copy[@]}))&&exit0cp-af--"${files_to_copy[@]}""${target_dir}/"

4.3.5 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/shESP_DIR="esp/EFI/arch"forfilein/boot/vmlinuz*;docp-af"$file""$ESP_DIR/$(basename"$file").efi"||exit1doneforfilein/boot/initramfs*;docp-af"$file""$ESP_DIR/"||exit1done[-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/"exit0

5. 高级管理

5.1 分区扩容与替换

当预装系统（如 Windows）创建的 ESP 过小（常见为 100 MiB）时，可能需要替换为更大的分区。

5.1.1 释放空间并新建分区

在 Windows 中，通过diskmgmt.msc压缩 C 盘（如释放 4 GiB），然后在 Linux 环境下执行以下操作：

1. 备份原 ESP 内容：

   cp-aesp /esp_backup

2. 卸载原 ESP，并停止相关 systemd 挂载单元：

   umountesp systemctl stop esp.mount esp.automount

3. 记录原分区的 UUID 与 PARTUUID：

   blkid /dev/sdXY

4. 使用 sgdisk 删除旧分区并新建（复用旧 PARTUUID 与 PARTLABEL）：

   sgdisk--delete=Y /dev/sdX 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

5. 通知内核重新读取分区表：

   partprobe /dev/sdX

6. 格式化为 FAT32 并复用旧 UUID（移除连字符）：

   mkfs.fat-F32-iXXXXXXXX /dev/sdXY

7. 挂载新分区并恢复数据：

   mount/dev/sdXY espcp-a/esp_backup/. esp/

5.1.2 牺牲相邻交换分区扩容

若 ESP 后紧邻交换分区，可删除交换分区以扩大 ESP：

1. 停用并移除交换分区；
2. 使用 fdisk 删除交换分区，然后扩大 ESP 分区至最大可用空间；
3. 由于fatresize及 libparted 对 FAT 卷的大小调整支持有限，通常需备份文件、创建新文件系统后恢复数据；
4. 记录并复用原 UUID；
5. 通过交换文件替代被删除的交换分区。

5.2 软件 RAID1 配置

将 ESP 纳入 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，并通过efibootmgr为次要 ESP 手动添加启动项。此方案避免了 RAID 的固件兼容性问题，但仅在单操作系统环境下有效。

5.3 休眠与多系统挂载策略

在多启动系统（包括 Windows 双启动）中，若希望在主系统休眠时启动至另一系统，严禁同时挂载同一 ESP，否则极易导致数据损坏与 I/O 错误。

缓解策略包括：

1. 独立 ESP：为每个系统分配物理上独立的 ESP（位于不同磁盘）。大多数 UEFI 固件支持此配置，但硬件支持与易用性存在差异。

2. 自动挂载：利用 systemd 自动挂载机制，仅在需要时挂载 ESP，并设置空闲超时（x-systemd.idle-timeout=）。注意：除非 ESP 挂载至/boot，否则不可在内核升级期间依赖自动挂载；此外，必须确保系统在自动卸载 ESP 之后才进入休眠。

3. 休眠前卸载：将 ESP 挂载至/efi，并在系统休眠前卸载，恢复后重新挂载。可创建 systemd 服务实现自动化：

   # /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依赖，停止它可能导致副作用。需在/etc/fstab中为/efi添加以下挂载选项：

   x-systemd.wanted-by=local-fs.target,x-systemd.after=local-fs-pre.target,x-systemd.before=local-fs.target

6. 实践排障

6.1 固件实现差异

尽管 UEFI 规范未对 ESP 的物理位置作强制限定，但工程实践中需考虑以下限制：

• LBA 寻址边界：2015 年后的主流 PC 采用 64 位 LBA，整块磁盘均可访问；但部分老旧固件及工控/服务器平台仍使用 32 位 LBA，最大寻址范围为2 32 − 1 2^{32} - 1232−1个扇区。在 512 B 扇区条件下，该上限对应 2 TiB。ESP 的全部扇区必须位于此边界以内，否则固件无法读取。
• 扫描范围：极少数 OEM 固件虽声称符合 UEFI 规范，但实现存在缺陷，仅扫描磁盘靠前的若干分区条目，导致位于磁盘中后部的 ESP 无法被识别。此现象属于固件实现缺陷，而非规范限制。

6.2 操作系统安装器行为

• Windows 安装程序：默认强制将 ESP 创建于磁盘靠前位置。若手动在磁盘中部或尾部新建 ESP，安装程序通常拒绝将其识别为安装目标，但手动执行bcdboot修复引导后仍可正常使用。
• Linux 安装器：大多数可识别任意位置的 ESP，但部分自动化脚本默认写死/dev/sda1，需手动指定 ESP 设备路径。

6.3 常见故障排除

固件无法识别 EFI 目录：若 FAT 文件系统被赋予了卷名（文件系统标签），切勿将其命名为EFI。某些固件会因卷名与目录名匹配而触发错误，导致无法识别 EFI 目录。

NVRAM 启动项失效：NVRAM 中的启动项记录的是磁盘 GUID 与分区 GUID，而非 LBA 位置。因此，仅移动分区的物理位置、分区本身未被删除时，启动项仍然有效；但若删除后重建 ESP，分区 GUID 改变，NVRAM 条目即告失效，需通过efibootmgr或bcdboot重新建立。

附录 1：常用 GPT 分区类型 GUID 对照

附录 2：Windows 环境下 ESP 操作命令

diskpart

diskpart list disk select disk X create partition efi size=260 format quick fs=fat32 label="System" assign letter=S exit bcdboot C:\Windows /s S: /f UEFI

PowerShell

New-Partition-DiskNumber 0-Size 260MB-GptType"EFI"|Format-Volume-FileSystem FAT32-NewFileSystemLabel"System"

注意：Windows 内置磁盘管理（diskmgmt.msc）不提供直接创建 ESP 的功能，其"新建简单卷"向导仅能创建基本数据分区。

附录 3：Linux 环境下 ESP 创建工具对照

附录 4：parted 分区起始不用 0，选用 1MiB 的原因

(parted)mkpart primary fat32 1MiB 261MiB

不能将0MiB作为起始地址，该限制由多重技术因素决定。

1. 磁盘 0 号位置不属于用户数据区域

磁盘 LBA0（第 0 号扇区）存放保护性 MBR（Protective MBR），用于防止旧版 MBR 工具误识别或误改写 GPT 磁盘。

GPT 磁盘结构如下：

• LBA0：保护性 MBR
• LBA1：GPT 头部（GPT Header）
• LBA2–LBA33：GPT 分区表项数组，最多容纳 128 个分区条目

LBA0–LBA33 属于 GPT 元数据区域，不可分配给用户分区。
若强行令分区从 0 开始，将直接覆盖 GPT 头部与分区表，导致分区表损坏。

2. 1MiB 是现代磁盘的标准对齐边界

现代 HDD 与 SSD 的物理块（Physical Block）或物理页大小已不限于传统 512 B：

• 多数设备物理块大小为 4 KiB（4096 B，即 4K 扇区磁盘）
• 1 MiB = 1024 KiB = 256 × 4 KiB

1MiB换算为扇区数：

• 512 B 逻辑扇区：1 MiB = 2048 扇区
• 4 KiB 逻辑扇区：1 MiB = 256 扇区

LBA 2048（即 1 MiB 处）与磁盘起始之间预留了 LBA0–LBA2047：

• LBA0–LBA33：保护性 MBR、GPT 头部、分区表
• LBA34–LBA2047：空闲间隙

分区自 LBA 2048（1 MiB）起始，可确保分区起始偏移量为物理块大小的整数倍，读写操作不会出现跨物理块访问，从而避免 SSD 与机械硬盘的性能下降。

该做法即通常所称的1 MiB 分区对齐。Linux 安装器与 parted 在新建分区时默认采用此偏移量。

3. 可否使用 34s（34 扇区）紧贴 GPT 表头？

parted 支持以扇区为单位（后缀s）。理论上可写：

mkpart primary fat32 34s 261MiB

LBA 34 是 GPT 分区表结束后的第一个空闲扇区，但实际中极少采用，原因如下：

1. 对齐问题：34s 的起始位置未对齐 1 MiB 边界，在 4 KiB 物理块磁盘上将导致分区未对齐，造成性能损失。
2. 兼容性：保留 LBA34–LBA2047 的空闲区域，可为部分固件、BIOS 私有数据或硬件隐藏元数据提供兼容空间。

4. 误区澄清：1MiB 并非分区开销

1MiB仅表示分区起始点，ESP 分区的实际可用容量为：

261 MiB − 1 MiB = 260 MiB 261\,\text{MiB} - 1\,\text{MiB} = 260\,\text{MiB}261MiB−1MiB=260MiB

5. 与 MBR 磁盘的对照

MBR 磁盘的 LBA0 存放 MBR 引导代码。传统工具常从第 63 扇区开始分区（受遗留 CHS 几何结构限制），该偏移量已不适用于现代磁盘。GPT 磁盘则直接采用 1 MiB（2048 扇区）作为通用起始偏移。

总结

1. LBA0–LBA33 存放保护性 MBR、GPT 头部及分区表，不可用于用户分区。
2. 1 MiB（LBA 2048）是工业界通用的对齐边界，适配 4 KiB 物理块磁盘，保障 I/O 性能。
3. 虽然可从 LBA 34 紧贴 GPT 表头开始分区，但会破坏对齐要求，通常不予采纳。
4. 因此，EFI 分区起始应写为1MiB，而非0MiB。

补充：在 parted 中若输入0作为起始位置，工具将自动发出警告并修正起始偏移，不会将分区实际置于 0 位置。

Reference

• 什么是 EFI 系统分区？ - 知乎
  https://zhuanlan.zhihu.com/p/262069479
• 主板 BIOS 的两种启动模式，传统模式 (Legacy) 和 UEFI 模式介绍-黑苹果动力
  https://www.mfpud.com/topics/1149/
• ESP（EFI System Partition，EFI 系统分区）完整解构 - suv789 - 博客园
  https://www.cnblogs.com/suv789/p/17503721.html
• EFI 系统分区 - ArchWiki - Arch Linux 教程
  https://wiki.archlinux.org.cn/title/EFI_system_partition