我记得当主板使用 BIOS 并且引导加载程序位于 MBR 中时，移动 Windows 分区会导致系统无法启动。我刚刚在朋友的 PC 上（意外地）移动了 C 分区（尝试调整其大小），该 PC 具有 GPT 分区表和 UEFI 主板 - 令我惊讶和高兴的是，PC 完美启动，没有抱怨分区第一个扇区的更改（我的朋友并没有生我的气）。我相信那是因为 UEFI 引导加载程序使用分区的 UID 而不是地址。
这让我想知道这是否意味着我可以在 GPT 系统上自由移动操作系统分区。这是否仅适用于 Windows 或也适用于 GRUB？
答案1
我相信这是因为 UEFI 引导加载程序使用分区的 UID 而不是地址。
这部分正确，但并非完全正确。正如您上面的陈述所暗示的那样，BIOS 模式引导加载程序通常依靠扇区号来帮助识别后续代码。也就是说，BIOS 读取 MBR 并执行其中包含的任何代码。MBR 太小，无法容纳真正灵活的引导加载程序，因此它将控制权传递给位于其他地方的代码，通常通过其扇区号来识别它，或者通过定位设置了引导标志的分区并运行该分区的 EBR（第一个扇区）中的代码。这个辅助引导加载程序代码可能会重复此过程，同样经常依赖于扇区号。因此，移动分区或从其起始点调整它们的大小可能会导致操作系统无法启动，因为引导加载程序代码本身已被移动。
相比之下，在 EFI 中，引导加载程序不是存储在 MBR 或分区的 EBR 中。相反，引导加载程序作为 EFI 程序文件存储在EFI 系统分区 (ESP)。这些程序文件可以根据需要设置大小（不超过文件大小、RAM 大小等的限制），因此引导加载程序不需要像 BIOS 引导加载程序那样进行拆分。此外，与 BIOS 不同，EFI 能够理解分区，因此 EFI 模式引导加载程序可以在需要时引用分区。
尽管 EFI 引导加载程序可能会通过其全局唯一标识符或者以其他方式，这并不是真正对您的问题重要的关键区别。当您移动分区时，BIOS 模式引导加载程序通常会中断，因为引导加载程序代码本身会移动；但在 EFI 中，引导加载程序位于文件中，而不是锁定到特定扇区的代码中。因此，移动 OS 分区不会移动引导加载程序代码。即使您移动了 ESP（引导加载程序所在的位置），EFI 也能理解分区和 FAT 文件系统，因此可以继续定位引导加载程序，只要 ESP 的标识信息和引导加载程序的文件名不会因此而改变。
这让我想知道这是否意味着我可以在 GPT 系统上自由移动操作系统分区。这是否仅适用于 Windows 或也适用于 GRUB？
一般来说，在基于 EFI 的系统上移动分区比在基于 BIOS 的系统上移动分区更安全。但我不会说它绝对 100% 安全。首先，移动分区操作始终存在导致文件系统损坏的风险。不过，这只是讨论此类操作时的标准警告。更切合你问题的问题是，引导加载程序可以以任何方式做任何他们想做的事情。虽然我不知道这方面的例子，但基于 EFI 的引导加载程序可以依靠原始扇区号来识别操作系统的内核，这使得移动内核所在的分区变得不安全。如果引导加载程序使用分区号等功能来识别带有内核的分区，并且移动分区会更改分区号，则移动分区后引导过程可能会失败。另一方面，如果分区号没有改变，移动分区可能不会产生任何问题。因此，分区移动操作的安全性取决于引导加载程序以及移动分区时发生的情况的细节。