我正在帮助一位朋友将他的操作系统从 500GB 机械驱动器迁移到新的 250GB SSD，但遇到了问题。从哪里开始呢？
他当前的操作系统是 Windows 10，使用 GPT 格式化，拥有 5 个分区，其中 3 个与系统相关，另外两个用于 Windows（第 3 个分区）和 Program Files（第 5 个分区）
移动一些数据后，所有分区的总使用空间约为 180GB。
我正在使用 Minitool Partition Wizard 的“将操作系统迁移到 SSD”向导来尝试迁移，过去对于基于 MBR 的磁盘，此向导曾多次可靠地发挥作用。
当我尝试迁移时，在选择目标磁盘（SSD）后，系统会要求我根据草图确认分区大小。在草图中，操作系统分区已缩小到最小大小，已占满 99%。第 4 个分区占据了磁盘的其余部分，程序分区却不见了。这实际上不是问题，最终目标不是将程序分区存储在 SSD 上，但它没有建议缩小程序分区，这确实有点奇怪，而且它确实表明迁移后分区位置会略有不同。
果然，一旦迁移完成并且 BIOS 更改以解决 SSD 问题，SSD 就无法启动了。要清楚的是，分区迁移成功，所有分区都存在且有效，只是驱动器无法启动。屏幕显示错误，基本上是告诉我找不到启动设备。我讨厌这种情况发生......
从引导扇区的角度来看，我不明白为什么找不到操作系统分区，它之前的分区移动了几 MB，但分区向导肯定会在进行这些更改后更新引导扇区，对吗？
在谷歌上搜索这个问题简直就是个笑话，所有的搜索结果都是来自软件供应商的 SEO 夸大的帖子，试图推销他们的各种盗版软件……
有人能帮我理解为什么软件管理的 GPT 分区迁移会破坏“可引导性”吗？如果需要，我可以发布分区安排的图像，以及错误的确切表述。
也许有一种方法可以合并操作系统和程序分区，但是它们被恢复分区分隔开，调整 GPT 分区大小后出现的所有这些启动问题让我很不安！
答案1
如果 SSD 还没有 EFI 系统、MS 保留和数据分区：
在 SSD 上手动创建 3 个分区（使用 diskpart.exe 或其他磁盘工具）：
EFI 系统 - 100 至 500 MB
MS 保留 - 正好 128 MB
数据（基本分区）- 磁盘剩余部分
然后使用任何可以备份恢复分区的工具将 Windows 分区从硬盘复制到 SSD 上的数据分区（推荐 Macrium Reflect，因为我已经使用过它）。
Reflect 还可以复制 ESP 和 MSR，因此您不需要手动创建分区。
然后使用以下命令修复 SSD 的启动：
bcdboot c:\windows /s S:
其中 c: 是 SSD 上的数据分区，S: 是 SSD 上的 EFI 系统。您可以使用 diskpart.exe 或 mountvol.exe 映射分区。
每个设备仅使用 EFI 启动！（禁用 CSM）
笔记：
引导扇区不用于在 GPT 磁盘上引导。EFI 系统分区保存引导相关文件，如引导管理器和 BCD。
答案2
仅供参考，gparted 是最好的分区软件。如果你有备用的 USB 驱动器，请安装 yumihttp://www.pendrivelinux.com/yumi-multiboot-usb-creator/，然后通过 yumi 安装 gparted。启动该棒并选择 gparted。你最好的朋友。从启动角度来看，它是 HD 还是 SSD 无关紧要 - 但如果 bios 设置错误，EFI 启动将无法工作。祝你好运。您还需要在 EFI 分区上设置启动标志（可以通过 gparted 完成）。
答案3
他当前的操作系统是 Windows 10，使用 GPT 格式化
在 Windows 启动盘上使用 GPT 意味着系统必须以 EFI/UEFI 模式启动。这很重要....
一旦迁移完成并且 BIOS 更改以解决 SSD 问题，SSD 将无法启动。... 我不明白为什么找不到操作系统分区，它之前的分区移动了几 MB，但分区向导肯定会在进行这些更改后更新引导扇区，对吗？
在 EFI 模式启动中，没有“启动扇区”这样的东西。EFI 启动加载程序作为普通文件存储在EFI 系统分区 (ESP)，即具有特定类型代码的 FAT 分区。这比使用分散到分区中的代码（甚至之间或者前分区，取决于引导加载程序），但这需要一些学习——并且联合国学习——掌握。
EFI 模式启动的关键之一是，对要使用的引导加载程序的引用存储在 NVRAM 中。这是基于 BIOS 的计算机上存储磁盘启动顺序的做法的扩展——只有在 EFI 下，启动顺序主要由以下内容组成文件，不是磁盘。（也可能有网络启动选项和磁盘上的后备文件启动，但这有点超出您的情况。）存储在 NVRAM 中的引导加载程序规范的一部分是与引导加载程序所在分区关联的 GUID 值。当您克隆磁盘时，新磁盘可能会获得新的 GUID，并且其分区都会获得新的 GUID。因此，您的 NVRAM 条目继续指向旧磁盘上的引导加载程序，您现在（大概）已将其断开连接。
这个问题通常可以通过使用“后备”引导加载程序来解决，它使用EFI\BOOT\bootx64.efiESP 上的名称。微软通常会在那里存储其引导加载程序的副本。我猜要么它没有被复制，要么你的固件配置为从未尝试过。如果是后者，你可以至少一次性地解决这个问题，方法是使用固件的内置引导管理器，它可能提供一个从后备文件名启动的选项（可能由磁盘的品牌和型号标识）。一些（太少了）EFI 还允许你通过使用文件管理器定位它来启动任意引导加载程序。如果你足够幸运地拥有这个选项，你可以EFI\Microsoft\Boot\bootmgfw.efi使用此功能启动正常的 Microsoft 引导加载程序（）。不过，这种一次性的努力不太可能成为可行的长期解决方案。为此，你可能必须使用 Windows 恢复工具重新安装你的 EFI 引导加载程序。我不是这方面的专家，但它似乎在这个问题和答案，所以你应该读一下它。
您的问题还有其他可能的原因，例如：
- 您的克隆实用程序可能完全忽略了 ESP。在这种情况下，您必须先创建一个新的 ESP，然后再修复引导加载程序问题。
- 一些制造商提供其自己的制造商特定的类似 ESP 的分区，这些分区对于启动过程至关重要。此类分区（如 ESP）可能在克隆过程中被省略。
- 您的克隆实用程序可能已创建原始 GPT 磁盘的 MBR 克隆。在这种情况下，最简单的解决方案可能是使用我的
gdisk公用事业或使用具有类似功能的其他工具将 MBR 转换为 GPT。您可能还需要创建一个新的 ESP，并且可能必须重新安装或修复现有的 Windows 引导加载程序安装。
也可能有其他可能的原因，但如果幸运的话，您现在可以检查磁盘并发现诸如分区表类型不正确或引导加载程序文件放错位置等问题。