参考：https://wiki.archlinux.org/index.php/GRUB#GUID_Partition_Table_.28GPT.29_specific_instructions
其他来源可能会引用 1MiB，但我对这个神奇数字真的很好奇。为什么不是 1000KiB 加上 24KiB 的差距？
答案1
引用的引文指的是BIOS 启动分区，它保存 BIOS 模式的 GRUB 代码。您引用的 wiki 对该问题的解释很差。BIOS 启动分区没有“魔法大小”，因为它保存的 GRUB 代码的大小可能因所使用的 GRUB 版本以及必须包含在该代码集中的特定功能（例如文件系统驱动程序）而异。过去，33KiB 已经足够大，但在今天的许多情况下，它需要更大。我曾看到有人声称某些安装实际上需要超过 1MiB，但我从未亲自验证过这一点。
看来 Arch wiki 作者过于关注优化磁盘布局；他们似乎希望磁盘上没有未分配的扇区。为了实现这一目标，他们主张创建一个大小奇怪的 BIOS 启动分区，以便它完全占据扇区 34（假设标准分区表大小，GPT 下的第一个可用扇区）和 2047（扇区 2048 之前的最后一个扇区，这是默认使用的第一个扇区，给定 2048 扇区对齐）之间的所有空间。假设 GRUB 代码适合 1007KiB，这样做没有错；但如果您接受所有分区（包括 BIOS 启动分区）上的默认 2048 扇区对齐，结果将是 1007KiB 的未分配磁盘空间和一个数据分区的大小减少 1MiB，与 wiki 建议的做法相比。鉴于现代磁盘的容量以 TB 为单位（换句话说，数百万次在我看来，如果将内存占用量（即节省 1MiB 空间的百分比）控制在 1MiB 以上（即浪费的空间大于浪费的空间），这种对保留 1MiB 空间的痴迷是错误的。
答案2
我不知道你从哪里得到这些“24KiB”和“1000KiB”的数字。引导分区太大了，所有可能的引导加载程序代码、配置文件、帮助文件、内核映像等都放在里面。在我看来，这个 1Meg 很小，因为
如今内核甚至可以达到 20MB 左右
它的大小需要过度声明，因为
让位于开始硬盘，从而移动开始第一个实际数据分区，通常是最困难的重新分区操作之一，
即使这个真正大的启动分区与今天的硬盘大小相比也是很小的（因为 200MB 在 4T 磁盘上实际上不算什么）。