Tell me more ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.
up vote 0 down vote favorite

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?

share|improve this question
for what it's worth, I just rebooted to Linux Mint, and the zeroed MBR is untouched, so it's not my BIOS's EFI firmware or the rEFInd boot loader (or grub, for that matter) that's messing with the MBR. It's got to be either the EFI Windows boot loader or Windows 7 itself. – littlenoodles Jan 25 at 16:52
Okay, I re-zeroed the MBR, and I'm in Windows 7 now with the SATA1 drive in place. I don't see anything in Disk Management or EasyBCD that would allow me to tell Windows 7 not to try to boot from SATA1. Does that mean my last hope is gone to have my old drive usable in both Windows and Linux without wiping out its partitions? And will wiping its partitions even help? – littlenoodles Jan 25 at 17:02
I see (again on Wikipedia) that the last 2 bytes of the MBR contain a hardcoded 'boot signature' value of 0xaa55, and indeed that's there on mine. Maybe wiping that would help. – littlenoodles Jan 25 at 21:57
Yipes!!! That didn't work. After zeroing the last 2 bytes of the MBR, Linux treated the partition table as invalid. After rebooting, the partitions 'weren't there', and fdisk reported the partition table as in error. I put back the old zeroed MBR (with only the first 446 bytes zeroed), and fdisk is happy again. – littlenoodles Jan 25 at 23:58

Know someone who can answer? Share a link to this question via email, Google+, Twitter, or Facebook.

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.