On my GPT/EFI-based new Windows 7 PC, I was trying to install my old PC's MBR-based drive as a secondary SATA1 disk. I've got Windows 7 and Linux Mint dual-booting on the new SATA0, but I still want to use the old disk as a secondary backup drive, and with the old MBR drive plugged in to SATA1, Windows 7 insists on trying to boot from it. Perhaps if I wiped the drive and went to a GPT partitioning scheme, I'd be okay, but I'm still not ready to completely blow away the partitions (and data) that are on there.
So I tried zeroing out the bootloader portion of the MBR by using dd to copy 446 bytes of zeros to the start of the drive. And that worked - kind of. With the bootloader freshly zeroed, I can boot Windows exactly once with the second disk plugged into SATA1. After that, Windows 7 again tries to boot from the second disk - except that now instead of loading the grub loader that used to be there, it gives me a 'no OS found' error. And the funny thing is that if I compare the zeroed MBR from before booting windows to the MBR after booting windows, it has changed:
cmp -l mbr.beforewindows mbr.afterwindows 441 0 161 442 0 342 443 0 312 444 0 50
Apparently Windows, in its infinite wisdom has modified the blank MBR. According to Wikipedia, MBR locations 440-443 are a '32-bit Disk signature (optional, UEFI, Windows NT/2000/Vista/7 and other OSes)' and location 444 is supposed to be 0. So, Windows 7 seems to see the drive and determine to make it bootable, messing up its own ability to boot with the drive present. Bravo, Microsoft!
Well maybe on that first boot where Windows does come up, I can see the drive in its Device Manager and tell Windows not to try to boot from it...
I seem to remember coming across a similar post somewhere with advice on how to stop Windows from trying to 'fix' the bootloader of the secondary drive. Does anybody know anything about this?