UEFI/GPT 和移动 C:\ 分区

Question

记得以前主板用BIOS，bootloader在MBR的时候，移动Windows分区导致系统无法启动。我刚刚在朋友的 PC 上（意外地）完成了 C 分区的移动（试图调整它的大小），它有一个 GPT 分区表和一个 UEFI 主板 - 令我惊讶和高兴的是，PC 完美启动，没有抱怨分区的第一个扇区（我的朋友没有生我的气）。我相信这是因为 UEFI 引导加载程序使用分区的 UID 而不是地址。

这让我怀疑这是否意味着我可以在 GPT 系统上自由移动操作系统分区。这也仅适用于 Windows 或 GRUB 吗？

Answer 1

我相信这是因为 UEFI 引导加载程序使用分区的 UID 而不是地址。

这部分正确，但不完全正确。BIOS 模式引导加载程序，正如您上面的陈述所暗示的，通常依赖扇区号来帮助识别后续代码。也就是说，BIOS 读取 MBR 并执行它包含的任何代码。MBR 太小，无法容纳真正灵活的引导加载程序，因此它将控制权传递给位于其他地方的代码，通常通过定位具有引导标志的分区并在 EBR（第一个扇区）中运行代码来通过扇区号来识别它) 的那个分区。这个辅助引导加载程序代码可能会重复这个过程，同样经常依赖于扇区号。因此，移动分区或从它们的起点调整它们的大小会使操作系统无法启动，因为引导加载程序代码本身被移动了。

相比之下，在 EFI 中，引导加载程序不存储在 MBR 或分区的 EBR 中。相反，引导加载程序作为 EFI 程序文件存储在EFI 系统分区 (ESP) 上。这些程序文件可以根据需要尽可能大（达到文件大小、RAM 大小等所施加的限制），因此引导加载程序不需要以 BIOS 引导加载程序通常被划分的笨拙方式进行拆分。此外，与 BIOS 不同，EFI 理解分区，因此 EFI 模式引导加载程序可以在需要时引用分区。

尽管 EFI 引导加载程序可能会通过其GUID或其他方式来定位分区，但这并不是对您的问题很重要的真正关键区别。当您移动分区时，BIOS 模式的引导加载程序经常会中断，因为引导加载程序代码本身会移动；但在 EFI 中，引导加载程序位于文件中，而不是锁定到特定扇区的代码。因此，移动操作系统分区不会移动引导加载程序代码。即使您移动了 ESP（引导加载程序所在的位置），EFI 也能识别分区和 FAT 文件系统，因此可以继续定位引导加载程序，只要 ESP 的识别信息和引导加载程序的文件名不会随着结果。

这让我怀疑这是否意味着我可以在 GPT 系统上自由移动操作系统分区。这也仅适用于 Windows 或 GRUB 吗？

作为一般规则，在基于 EFI 的系统上移动分区比在基于 BIOS 的系统上移动更安全。不过，我不会说它绝对是 100% 安全的。首先，始终存在分区移动操作会导致文件系统损坏的风险。不过，这只是在讨论此类操作时的标准警告。更重要的是，引导加载程序可以以任何他们想要的方式做任何他们想做的事情。虽然我不知道这方面的例子，但基于 EFI 的引导加载程序可以依靠原始扇区号来识别操作系统的内核，这会使移动内核所在的分区变得不安全。如果引导加载程序使用分区号等功能来识别具有内核的分区，并且如果移动分区更改了分区号，则在移动分区后引导过程可能会失败。OTOH，如果分区号没有改变，移动分区可能不会产生问题。因此，分区移动操作的安全性取决于引导加载程序和移动分区时发生的详细信息。