前几天干了个事，详情见《用复制粘贴的方式迁移系统》。通常来说干这种事情有两种动机，一是把一份有用的系统从老机械硬盘上迁移到 SSD 上，一种是随便把一个现成的系统复制出来要折腾它，这次是前者。
迁移出来的系统，原来运行于 ThinkPad X200 上，当时安装的时候，出于对 X200 的能力的怀疑，装了一个精简版的 Windows 10 上去，而现在既然迁移到了 ThinkPad T440p 上，虽说 CPU 才是个 i5 4300m，但好歹是标压的，把系统更新到最新的完整版应该可以承受。
把手里现成的 Windows 10 专业版、最新的 1909 版的 U 盘插上，运行 setup.exe，过不多时，竟然报了个从未见过的“抱歉， 我们很难确定你的电脑能否运行windows 10”的错误（下图来自网络）。
在网上检索一番，看有网友言道，出现此问题的机器，有个现象就是打开 msconfig 会发现“引导”那一页里面的可引导项没有内容。我一看，还果真如此。只不过他的机器是 UEFI 引导，而我的是 BIOS 方式。尽管如此，我还是把怀疑重点放到了 Grub 上，毕竟是它在引导方面取代了 Windows 自己的 bootmgr。
在对 BIOS 方式的引导过程，以及 MBR 等引导扇区的组织进行了一番了解之后（详情见上篇博文《MBR 格式磁盘布局》），制定了一个测试方案如下：
- 将当前的 Grub 占据的 MBR 备份（为了准确验看 Windows 的 MBR 会占用几个扇区，实际操作中备份了两份，一份是仅仅 MBR 一个扇区，一份是 Grub 占用的全部 63 个扇区）；
- 写入 Windows 的 MBR；
- 把活动分区设到 Windows 所在分区；
- 如果重启 Windows 正常，执行升级；
- 如果升级成功，备份 Windows 的 MBR，以防后续尝试恢复 Grub 的 MBR 失败导致鸡飞蛋打哪个系统都进不去；
- 写入备份的 Grub 引导扇区；
- 把活动分区标识设回到 Linux 的 boot 分区；
- 重启查看是否正常。
先说结论：此流程非常完美。再说用到的工具，开始走了弯路，下载了一个叫 HDHacker 的工具，保存的 MBR 文件在界面上显示 337 字节，磁盘上则是 400 多字节，跟我预期的 446 或者 512 字节都对不上，跟 MBR 一比对，乖乖，从第四五和字节就开始不一样了，吓得赶紧删掉了。后来还有几个，其中只有一个 MBR Backup 还勉强能用。后来才想起来 Bootice，发现就它一个就足够用了。
还有一个结论是，Windows 自己的 MBR 没有那么贪，只用了规定的 MBR 扇区，其他保留扇区都没动。