答案1
通常,当 BIOS 样式的 GRUB 安装到 MBR 中时,它也会占用实际 MBR 块之后的前几个块。但在 GPT 分区的磁盘上,GPT 分区表位于同一位置,因此是预先存在的 GRUB 的重要组成部分必须已被新的 GPT 分区表覆盖。
如果转换正确执行,您的文件就没有问题:损坏将仅限于 GRUB 引导加载程序,该引导加载程序(在其 BIOS 风格系统的版本中)的重要部分位于分区外本质上是嵌入式二进制代码的原始片段。如果您使用实时 Linux 介质启动系统,您现在应该能够挂载分区并正常访问其中的文件。
使用 UEFI,不会发生此问题,因为 UEFI 引导加载程序完全包含为文件。如果未使用安全引导,则 UEFI 版本 GRUB 的核心部分将包含在一个*.efi
文件中,通常grubx64.efi
位于特殊的 ESP 分区上,这是任何 UEFI 引导加载程序的标准位置,其余部分可以作为模块加载根据需要创建文件。
如果 MBR 分区磁盘以 UEFI 方式启动,则 ESP 通常是一个 FAT32 分区,其特殊类型 ID 为 0xEF。在 GPT 分区磁盘上,ESP 有一个专用的 UUID 类型标识符,基本上所有 GPT 分区程序都知道该标识符。
Windows 不支持将 BIOS 式引导过程与 GPT 格式的系统磁盘结合使用,因此系统制造商可能根本没有测试过这种情况。然而,理论上它应该可以正常工作,前提是为 GRUB 的正常位置现在与 GPT 分区表本身冲突的部分提供了合适的新位置。这个新地点将是BIOS启动分区,我相信 Oldfred 指的是BIOS_grub分区在评论中。
BIOS 引导分区的大小不需要大于 1 MiB,但现在需要创建这样的分区并重新安装 GRUB,以便它将使用该分区来嵌入新 GPT 分区表所取代的组件。
如果您至少有 1 MiB 的可用未分区空间,或者可以安全地将现有分区之一缩小这么多,则可以使用实时 Linux 启动介质来创建 BIOS 启动分区并相应地设置其类型。如果您在其他地方没有可用空间,但有交换分区,则删除当前交换分区并重新创建 1 MiB 小的分区将是为 BIOS 引导分区获取可用空间的一种简单方法。
然后,您必须安装现有的根分区(以及必要时的任何其他分区),chroot 到其中,验证当前版本是否grub-install
支持 BIOS 引导分区,并使用它在现在采用 GPT 分区的系统磁盘上重新安装 GRUB。
但我同意oldfred在评论中的建议:为了确保没有其他问题,你应该先准备一个可引导的引导修复实用程序(可能使用其他计算机),然后在您的计算机中使用它来生成当前情况的报告并在此处发布指向该报告的链接。
我还想问:你为什么首先要做这个转换?如果您使用 BIOS 式引导并且当前系统磁盘大小小于 2 TiB,则转换为 GPT 分区的好处非常有限。如果您计划迁移到更大的系统磁盘,那么使用新磁盘进行迁移会更安全,这样您只需用旧磁盘替换新磁盘,然后在转换出现问题时重试。