UEFI 系统分区的最小大小是多少？

Question 1

是否只是因为现代操作系统使用量很大就推荐使用 100？

请注意，100 MB 分区大小是最小值。虽然 UEFI 没有设置最小大小的规范，但微软建议操作系统使用 100 MB 大小。

假设我们需要使用 FAT32 文件系统格式化 EFI 分区。FAT32 驱动器的最小分区大小计算如下sector_size x 65527。

在高级格式 4K Native 驱动器中，每个扇区有 4 KB。在这种情况下，FAT32 驱动器的最小分区大小计算为4 KB x 65527 = 256 MB. 这就是为什么建议 4K 驱动器的最小大小为 260 MB。

但在高级格式 512e 驱动器中，模拟扇区大小为 512 字节。在这种情况下，FAT32 驱动器的最小分区大小计算为512 bytes x 65527 = 32 MB，小于此分区的最小大小 100 MB。

EFI 分区是否必须达到一定的大小系统才能识别它？

尽管微软建议其操作系统使用 100 MB，但 Linux 论坛建议基于 Linux 的操作系统或任何双重启动或多重启动情况使用更大的内存。

这作者gdisk 建议使用 550 MiB。

根据 Arch Linux论坛，为避免某些 EFI 可能出现的问题，ESP 大小至少应为 512 MiB。建议使用 550 MiB，以避免 MiB/MB 混淆并意外创建 FAT16。

因此，EFI 系统分区最常见的大小准则是 100 MB 到 550 MB 之间。其中一个原因是，由于它是驱动器上的第一个分区，因此以后很难调整大小。EFI 分区可能包含语言、字体、BIOS 固件和其他固件相关内容。有些固件/软件安装在 EFI 分区中，而不是数据驱动器中。有些人希望将来能够将东西添加到 ESP 中。

由于以后需要时可能很难扩大大小，而且现在的硬盘容量更大，因此建议为 ESP 设置较大的大小，例如 100 MB 或 550 MB。但一般情况下，它仅使用几千字节的空间。

假设我有一个闪存驱动器，并且我希望它可启动。

虽然从您的陈述中看不清楚，但如果您尝试让您的 pen 驱动器作为 UEFI 兼容驱动器启动，用于 Windows 安装，则无需在 pen 驱动器中创建额外的 ESP。使用鲁弗斯或类似工具，可将其转换为支持 UEFI 的驱动器。但在硬盘驱动器中安装 Windows 时，需要在该驱动器中安装 ESP。

Answer

是否只是因为现代操作系统使用量很大就推荐使用 100？

请注意，100 MB 分区大小是最小值。虽然 UEFI 没有设置最小大小的规范，但微软建议操作系统使用 100 MB 大小。

假设我们需要使用 FAT32 文件系统格式化 EFI 分区。FAT32 驱动器的最小分区大小计算如下sector_size x 65527。

在高级格式 4K Native 驱动器中，每个扇区有 4 KB。在这种情况下，FAT32 驱动器的最小分区大小计算为4 KB x 65527 = 256 MB. 这就是为什么建议 4K 驱动器的最小大小为 260 MB。

但在高级格式 512e 驱动器中，模拟扇区大小为 512 字节。在这种情况下，FAT32 驱动器的最小分区大小计算为512 bytes x 65527 = 32 MB，小于此分区的最小大小 100 MB。

EFI 分区是否必须达到一定的大小系统才能识别它？

尽管微软建议其操作系统使用 100 MB，但 Linux 论坛建议基于 Linux 的操作系统或任何双重启动或多重启动情况使用更大的内存。

这作者gdisk 建议使用 550 MiB。

根据 Arch Linux论坛，为避免某些 EFI 可能出现的问题，ESP 大小至少应为 512 MiB。建议使用 550 MiB，以避免 MiB/MB 混淆并意外创建 FAT16。

因此，EFI 系统分区最常见的大小准则是 100 MB 到 550 MB 之间。其中一个原因是，由于它是驱动器上的第一个分区，因此以后很难调整大小。EFI 分区可能包含语言、字体、BIOS 固件和其他固件相关内容。有些固件/软件安装在 EFI 分区中，而不是数据驱动器中。有些人希望将来能够将东西添加到 ESP 中。

由于以后需要时可能很难扩大大小，而且现在的硬盘容量更大，因此建议为 ESP 设置较大的大小，例如 100 MB 或 550 MB。但一般情况下，它仅使用几千字节的空间。

假设我有一个闪存驱动器，并且我希望它可启动。

虽然从您的陈述中看不清楚，但如果您尝试让您的 pen 驱动器作为 UEFI 兼容驱动器启动，用于 Windows 安装，则无需在 pen 驱动器中创建额外的 ESP。使用鲁弗斯或类似工具，可将其转换为支持 UEFI 的驱动器。但在硬盘驱动器中安装 Windows 时，需要在该驱动器中安装 ESP。

Question 2

你可以承受的绝对最小大小涉及使用 fat12 文件系统（因此32 千字节)，实际上需要使用一些最小的启动管理器，该管理器包含文件系统驱动程序来读取主分区（以及其中包含的内核），这意味着 grub 或 rEFInd。典型的 grub-install 映像大约为 200KB，这仍然不算太糟。

我已经使用 2MB fat12 ESP 顺利启动了一段时间了，显然这是可以做到的！

我不完全确定使用 512MB 的常见建议来自哪里，但是建筑维基最近被我修改了，以参考 fat12 的可能性。

http://www.rodsbooks.com/linux-uefi/似乎表明至少 fat16 应该可以正常工作，除了混淆 Windows 安装程序，在我看来这其实并不相关。Arch Wiki 似乎是基于这个建议，但我没有足够的勇气完全重写它。

正如我在 Wiki 中提到的，UEFI 规范强制使用 fat12 驱动程序。我听说过“只强制使用可移动驱动器”的说法，这留下了一种可能性，即某个地方的某个人已经或将要编写一个包含这些 fat12 文件系统驱动程序的 UEFI 实现，但以某种方式禁止使用它们来挂载 UEFI 系统分区，但我个人认为这种情况不太可能发生。

Answer

你可以承受的绝对最小大小涉及使用 fat12 文件系统（因此32 千字节)，实际上需要使用一些最小的启动管理器，该管理器包含文件系统驱动程序来读取主分区（以及其中包含的内核），这意味着 grub 或 rEFInd。典型的 grub-install 映像大约为 200KB，这仍然不算太糟。

我已经使用 2MB fat12 ESP 顺利启动了一段时间了，显然这是可以做到的！

我不完全确定使用 512MB 的常见建议来自哪里，但是建筑维基最近被我修改了，以参考 fat12 的可能性。

http://www.rodsbooks.com/linux-uefi/似乎表明至少 fat16 应该可以正常工作，除了混淆 Windows 安装程序，在我看来这其实并不相关。Arch Wiki 似乎是基于这个建议，但我没有足够的勇气完全重写它。

正如我在 Wiki 中提到的，UEFI 规范强制使用 fat12 驱动程序。我听说过“只强制使用可移动驱动器”的说法，这留下了一种可能性，即某个地方的某个人已经或将要编写一个包含这些 fat12 文件系统驱动程序的 UEFI 实现，但以某种方式禁止使用它们来挂载 UEFI 系统分区，但我个人认为这种情况不太可能发生。

Question 3

对于 Linux，在终端中运行sudo fdisk -l以找出存储驱动器的扇区大小。

由于 EFI 分区的格式为 FAT32，因此 FAT32 驱动器的最小分区大小计算为sector_size x 65527。对于现代存储，该大小为 512 字节 x 65527 = 32 MiB。EFI 启动管理器可执行文件约为 125 KiB，因此 32 MiB 的最小值对于 EFI 分区大小来说是必要的。还有其他理由要求更大的尺寸，但除非您在这些特殊情况下运行，否则不需要更大的尺寸。

Answer

对于 Linux，在终端中运行sudo fdisk -l以找出存储驱动器的扇区大小。

由于 EFI 分区的格式为 FAT32，因此 FAT32 驱动器的最小分区大小计算为sector_size x 65527。对于现代存储，该大小为 512 字节 x 65527 = 32 MiB。EFI 启动管理器可执行文件约为 125 KiB，因此 32 MiB 的最小值对于 EFI 分区大小来说是必要的。还有其他理由要求更大的尺寸，但除非您在这些特殊情况下运行，否则不需要更大的尺寸。

Question 4

@Original poster：您想知道 EFI 分区所需的最小大小，但您没有说明您考虑的是什么操作系统。没有单一的要求。阅读互联网上的信息，有些人说“2 mb”（以上），而其他人则建议 TB 级的空间。我建议每个人都写下他们自己系统的最低要求，然后我们就会有一个所有操作系统要求的列表。所以让我回答你关于 Debian 操作系统的问题：

uname -r

5.10.0-6-amd64

uname -a

Linux localhost 5.10.0-6-amd64 #1 SMP Debian 5.10.28-1 (2021-04-09) x86_64 GNU/Linux

和 Windows 10：

ver

Microsoft Windows [Version 10.0.19042.804]

现在，在安装 Debian 时，我想知道 EFI 分区所需的大小。这就是我找到这个页面的方式，但这里提供的信息没有帮助。所以我想，5mb 够了吗？事实证明 Debian 安装程序的最低要求是 35mb。

请注意，如果您先使用 fdisk 对 EFI 分区进行分区，然后尝试安装 Debian，它将拒绝并显示一条神秘的错误消息：

The attempt to mount a file system with type vfat in SCSII (0,0,0), partition #1 (sda) at /boot/efi failed.

如果您比较 fdisk 和 Debian 安装程序设置的标志（如果您允许它进行分区）：

fdisk -> "B K"

Debian -> "B f"

重新选择 Debian 安装程序中的 EFI 分区来修复标志。愚蠢的 Debian。

此外，在 Hyper-V 中使用 fdisk 时，无法显示分区十六进制代码列表，因为增强模式 (VmConnect) 不起作用，SSH 未安装，因此 fdisk 输出的十六进制代码列表一闪而过，而且无法向上滚动 VmConnect 窗口。在 VMWare Workstation 中，可以通过 SHIFT+PageUp 来实现，但我不知道如何在 Hyper-V 中做到这一点，事实上，甚至没有人提出这个问题！所以我终于发现，EFI 分区在 fdisk 中是“1”。

无论如何，Debian 安装程序所需的空间量真的需要吗？安装 Debian 后，我检查了实际所需的空间：

mount /dev/sda1 /mnt

cd /mnt

du -hs

/efi/debian
    -rwx------ 1 root root    1K 27. Apr 00:11 BOOTX64.CSV
    -rwx------ 1 root root 1180K 27. Apr 00:11 fbx64.efi
    -rwx------ 1 root root    1K 27. Apr 00:11 grub.cfg
    -rwx------ 1 root root 1634K 27. Apr 00:11 grubx64.efi
    -rwx------ 1 root root 1233K 27. Apr 00:11 mmx64.efi
    -rwx------ 1 root root 1292K 27. Apr 00:11 shimx64.efi

5,3M

5.3M！你竟然还敢说 550MB、1GB、10TB，还有什么出价吗？！有些人会说，grub 引导加载程序位于 EFI 分区，其他人则说“update-initramfs”会写入此分区，这就是为什么需要这么多空间。胡说八道，全是胡说八道！

但是，唉，损害已经造成了，现在我必须处理它。

mount /dev/sda1 /mnt

cp -r /mnt/EFI /work

umount /dev/sda1

blkid

/dev/sda1: UUID="6995-68F6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a7196942-ec1b-e64a-9182-009a28d2cc44"

gdisk /dev/sda
d 1
n 1
+5466KB
EF00
w

umount /dev/sda1

mkfs.fat /dev/sda1

mount /dev/sda1 /mnt

mv /work/EFI /mnt

umount /dev/sda1

修复 PARTUUID：

partprobe /dev/sda

blkid

gdisk /dev/sda

x
c (1) -> set the old PARTUUID (a7196942-ec1b-e64a-9182-009a28d2cc44 in my example)

修复 fstab 中的 UUID：

nano /etc/fstab -> set the new UUID

为什么是“mkfs.fat”（上面），而不是“mkfs.fat -F32”？原因如下：

https://github.com/dosfstools/dosfstools/blob/master/src/mkfs.fat.c

According to Microsoft FAT specification (fatgen103.doc) disk with 65525 clusters (or more) is FAT32

define MIN_CLUST_32 65525

diskpart 也将拒绝格式化为 fat32：

format fs=fat32 quick

Volume too small

因此，节省了 30mb 的空间，但尚未分配。如何分配？运行 fdisk，删除 ext4 分区并重新创建它（包括未分配的空间（dn，所有默认值））会导致系统无法启动。在网上，他们会告诉你，在分区之前用未分配的空间扩展分区是不可能的，需要将原始空间移动到硬盘的末尾，然后扩展。如何将未分配的空间移动到末尾？不知道。试过 fdisk、gdisk、parted、MS diskpart。找不到。所以我最终下载了“gparted-live-1.2.0-1-amd64.iso”。gParted 能够用未分配的空间扩展 ext4 分区，但它在硬盘末尾留下了 1mb 的空间。在网上，他们会告诉你，这是按照规范完成的。真的吗？有趣的是，fdisk 不会将这一兆字节留在最后，微软的 diskpart 在扩展分区时也不会这样做。网上有人说，“它只有 1 兆字节，你不想违反规范来保存它。”我会保存这一可怜的兆字节，即使我必须践踏那里的所有规范！别担心，可怜的被忽视的兆字节，我会拯救你的！

所以我欺骗了 gParted，呵呵。我将未分配的空间移到了磁盘末尾，没有分配它。然后我关闭了 gParted，改用 fdisk 来扩展 ext4 分区，它为它分配了所有空间，包括可怜的兆字节：

fdisk /dev/sda

F
    Start   End     Sectors Size
    14336   73727   59392   29M

d 2
n 2 14336

fdisk -l

Device     Start      End  Sectors  Size Type
/dev/sda1   2048    12979    10932  5,3M EFI System
/dev/sda2  14336 20971486 20957151   10G Linux filesystem

关于 Windows。MS 说，100 MB efi + 16 mb msr。当然，臭名昭著的复制粘贴者总是不加检查地复制粘贴信息，并将这些错误信息传播到互联网上。但这个空间量真的有必要吗？让我们看看 EFI 分区中有什么：

 Verzeichnis von B:\efi\boot

    1.558.344 bootx64.efi

Verzeichnis von B:\efi\microsoft\boot

    28.672 bcd

Verzeichnis von B:\efi\microsoft\boot\fonts

    48.992 wgl4_boot.ttf

Anzahl der angezeigten Dateien:
           3 Datei(en), 1.636.008 Bytes

我专门为你打印了这份清单，我知道那里面有什么，因为我自己把文件放在那里，当时我正在用 dism 将 Windows 映像恢复到 EFI 机器（该映像是由 dism 在 MBR 机器上创建的）。几乎不可能找出哪些文件是真正需要的。通过反复试验，我发现，你只需要上面的 3 个文件

diskpart

select disk 0

select partition 1

assign letter b

mkdir b:\efi
mkdir b:\efi\boot
mkdir b:\efi\microsoft
mkdir b:\efi\microsoft\boot
mkdir b:\efi\microsoft\boot\fonts

copy c:\windows\boot\efi\bootmgfw.efi b:\efi\boot\bootx64.efi

copy c:\windows\boot\fonts\wgl4_boot.ttf b:\efi\microsoft\boot\fonts

bcd存储你要自己创建，这里就不细说了，然后：

copy X:\bcd b:\efi\microsoft\boot

所以是 1.636.008！微软说的是 116mb？而这些信息被复制粘贴到了整个互联网上。我一开始是按照那些说明操作的，我是个白痴，但现在我想看看微软要求的大小是否真的需要（比如让 Windows 无法启动）：

dism /Capture-Image /ImageFile:c:\copy\efi.wim /CaptureDir:b:\ /Name:efi /Compress:fast

diskpart

select disk 0

select partition 0

delete partition override
    efi killed

select partition 1

delete partition override
    msr killed

create partition efi size=2

format fs=fat quick

assign letter b

dism /Apply-Image /ImageFile:c:\copy\efi.wim /Index:1 /ApplyDir:b:\

祈祷吧，我要重启了！休斯顿，报告 Windows 火箭成功发射！……休斯顿，报告 Windows 启动和账户登录成功！休斯顿，微软是一群该死的骗子！

因此我们节省了 114 mb，但该空间尚未分配。

磁盘分区？

哈哈哈！

磁盘管理控制台

哈哈哈哈哈哈！

然后呢？我猜又是 gParted。使用 Linux 程序来处理 NTFS 分区并不是一个好主意，但让我们试试吧。所以我将未分配的空间移到了硬盘的末尾。成功了。再次从 DVD 重新启动 Windows（在我的情况下是带有已安装 ISO 的虚拟 DVD，因为我是在 Hyper-V 中执行此操作），然后：

diskpart

select disk 0

select partition 1

extend

完毕。

list partition

Partition ###  Typ               Größe    Offset
-------------  ----------------  -------  -------
Partition 1    System            2048 KB  1024 KB
Partition 2    Primär              39 GB  3072 KB

select partition 1

detail partition

Volume ###  Bst  Bezeichnung  DS     Typ         Größe    Status     Info
----------  ---  -----------  -----  ----------  -------  ---------  --------
* Volume 1                      FAT    Partition   2048 KB  Fehlerfre  System

但是，如果您想通过 Linux 工具删除 EFI 和 MSR 分区，该怎么办？我不知道为什么，但这样做会导致 Windows 系统无法启动。我向 gdisk/fdisk/parted 传递了与 diskpart 完全相同的参数，但所有这些工具都会破坏某些东西！在 diskpart 中删除 MSR 分区：

select partition 1

delete partition override

重新启动，Windows 启动。

gdisk 中也有同样的事情！：

gdisk /dev/sda

d (select msr partition)
w

重启后，我看到了该死的 Hyper-V 徽标，它一直在那里，系统无法启动。原因是什么？

Answer