在我基于 GPT/EFI 的新 Windows 7 PC 上，我尝试将旧 PC 的基于 MBR 的驱动器安装为辅助 SATA1 磁盘。我在新的 SATA0 上安装了 Windows 7 和 Linux Mint 双启动，但我仍然想使用旧磁盘作为辅助备份驱动器，而将旧 MBR 驱动器插入 SATA1 后，Windows 7 坚持尝试从它启动。也许如果我擦除驱动器并转到 GPT 分区方案，那就没问题了，但我还没有准备好完全清除那里的分区（和数据）。
因此，我尝试使用 dd 将 446 个字节的零复制到驱动器的开头，以清零 MBR 的引导加载程序部分。这招很管用。将引导加载程序清零后，我可以启动 Windows恰好一次将第二个磁盘插入 SATA1。之后，Windows 7 再次尝试从第二个磁盘启动 - 只不过现在它不再加载以前存在的 grub 加载程序，而是给出“未找到操作系统”错误。有趣的是，如果我将启动 Windows 之前的归零 MBR 与启动 Windows 之后的 MBR 进行比较，它已经发生了变化：
cmp -l mbr.beforewindows mbr.afterwindows
441 0 161
442 0 342
443 0 312
444 0 50
显然，Windows 凭借其无穷的智慧修改了空白的 MBR。根据 Wikipedia，MBR 位置 440-443 是“32 位磁盘签名（可选，UEFI、Windows NT/2000/Vista/7 和其他操作系统）”，位置 444 应该是 0。因此，Windows 7 似乎看到了该驱动器并决定使其可启动，从而扰乱了其在驱动器存在的情况下启动的能力。太棒了，微软！
嗯，也许在第一次启动 Windows 时做出现后，我可以在其设备管理器中看到该驱动器并告诉 Windows 不要尝试从它启动...
我似乎记得在某个地方看到过类似的帖子，其中有关于如何阻止 Windows 尝试“修复”辅助驱动器的引导加载程序的建议。有人知道这方面的信息吗？