Windows boot loader insists on booting from secondary SATA drive

Unanswered Windows boot loader insists on booting from secondary SATA drive

  • Saturday, January 19, 2013 3:36 PM
     
     

    I already posted a variant of this in another section, but I see similar questions here, so...

    I just bought a new PC (HP P7-1380t, motherboard:  H-Joshua-H61-uATX) with Windows 7, a GPT partitioning scheme and Windows 7 set up to boot in EFI mode.

    I'm trying to add the SATA drive from my old XP system as a secondary drive on the new box - both to copy files over and to have as a backup drive.  The old box was set up as a dual boot XP, Linux system with the grub bootloader in the MBR.

    When I plug the old drive into SATA1, launch the windows boot loader in EFI mode from SATA0, and select Windows 7 to boot (the only choice there), the windows boot loader tries to boot from SATA1.  It displays a progress meter with the message "Windows is loading files", and then it displays the grub boot menu (presumably from the old drive's MBR).  Why is this happening?  It seems like the boot loader is reinitializing itself based on detecting 'new hardware', and it decides that it should boot from the drive in SATA1.  When I tried disabling SATA1 in the BIOS's 'legacy boot order' section (the EFI boot order section doesn't list individual hard drives - just the windows boot loader), The windows boot loader starts, but when I select Windows 7, it says 'drive not found'.  In other words, even with SATA1 disabled in the BIOS boot order, the windows boot loader is trying to boot from it.  By the way, the same thing happens if I plug in a bootable flash drive (and don't plug in the old SATA1 drive).  I select Windows 7 from the boot loader menu, the Windows boot loader says "windows is loading files" and then boots the flash drive.

    Is there a way to tell the windows boot loader never to attempt to boot from SATA1?  I've seen some answers that say I can disable a disk in the Disk Management tool, but the disk doesn't show up there if it's not plugged in - and I can't boot and get to the tool with the disk plugged in.  Catch-22.  I don't have a bootable Windows DVD - this is an OEM install.  The boot menu as shown in EasyBCD lists 'hard drive' as an option in addition to Windows 7.  I tried moving that below Windows 7 in the menu, with no effect - and after rebooting, it was back in its original place.  In either case, I am not presented anything but Windows 7 in the actual menu, so I don't know if the other entries are enabled or not.

    For what it's worth, if I plug the same drive into SATA3 instead of SATA1, Windows 7 boots normally and can see the drive as F:.  But plugged in that way, the BIOS doesn't show it in its legacy boot order screen, and a linux system booted from CD doesn't see it.  In SATA1, linux sees it fine.  I'd like the option to dual boot, so I really want to make this SATA1 (or make the BIOS see it as SATA3...).

    I'm guessing that if I were to wipe the old drive and repartition it as a non-bootable drive, this problem might go away.  But I don't want to wipe it until I get the new drive set up for dual boot and all the data copied from the old drive to the new drive.

    Thanks,
    Rob

All Replies

  • Saturday, January 19, 2013 5:22 PM
     
     

    It sounds like you do not have your UEFI setup correctly, check your settings carefully.

    If you need help with your UEFI settings, you need to contact HP Technical Support.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Monday, January 21, 2013 12:04 AM
     
     

    It sounds like you do not have your UEFI setup correctly, check your settings carefully.

    If you need help with your UEFI settings, you need to contact HP Technical Support.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    HP gives lots of unhelpful information and then finally says 'we don't support dual-booting'.  Gee, thanks.  I've given up on trying to use the old drive in SATA1.  With that drive there, the windows boot loader will default to booting from a CD drive or the old SATA1 drive - anything but SATA0 where Windows 7 lives.  It's pretty strange.

    The UEFI settings on the machine are pretty limited.  There seems to be no way to get a CD or DVD to boot in EFI mode (i.e. with the EFI firmware enabled so the booted OS can install in EFI mode) - unless the windows boot loader can be convinced to do it...  (If someone knows how to do that, I'd appreciate it).  Obviously, there's a way - you need to be able to install Windows from a CD, no?  I even tried disabling the windows boot loader (only EFI option presented) to see if it would then give me an option to boot from CD in EFI mode.  I guess it might, if the CD had an EFI directory structure on it...

  • Saturday, January 26, 2013 3:49 PM
     
      Has Code

    I found a workaround that works - with a big caveat.  It's only good for a single boot, and then it reverts to no longer working.

    If I zero out the bootloader portion of the MBR by using dd to copy 446 bytes of zeros to the start of the drive, Windows will boot with the drive there. 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.

    Is there a way to prevent Windows from trying to automatically 'fix' the MBR on the second drive, when I boot it from the first drive?

    Ultimately, I guess, I can wipe the second drive and replace it's MBR partitioning scheme with GPT - I assume windows won't try to boot that... But I'd really like to keep my options open (including the option of putting the old drive back into the old computer and giving it away).

  • Saturday, January 26, 2013 4:33 PM
     
     

    The normal UEFI works correctly with Windows 7 64-bit.  I have an ASRock MB with UEFI and it does not have "secure" boot so it works fine!

    Your problem is caused by the UEFI wanting to secure boot, not by Microsoft messing with the MBR!!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Sunday, January 27, 2013 4:02 PM
     
     

    The normal UEFI works correctly with Windows 7 64-bit.  I have an ASRock MB with UEFI and it does not have "secure" boot so it works fine!

    Your problem is caused by the UEFI wanting to secure boot, not by Microsoft messing with the MBR!!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”


    No, that's not the problem.  I don't have 'secure boot' enabled, and I am able to boot windows 7 and Linux Mint from the first (SATA0) drive when the second drive is not plugged into SATA1 (plugging it into SATA3 does not cause a problem with booting - but it causes other problems).  It's when I ask the EFI bootloader to load windows, and presumably am now running the windows bootloader that the problems arise.  The windows boot loader sees an MBR on the second SATA1 drive and tries to boot from it.  If I zero out that bootloader, the Windows boot loader does not try to boot from it, and boots Windows 7 successfully from SATA0.  But the next time I try to boot Windows, it's back to trying to boot from the SATA1 MBR - and when I look at that MBR, it's no longer zeroed.  Windows itself has filled in bytes 441-444 with some kind of bootloader signature that then causes Windows to try to boot that MBR in the future.  It's that patching of the MBR that I want to prevent Windows from doing, but I don't know where that's controlled.
  • Sunday, January 27, 2013 6:03 PM
     
     

    The normal UEFI works correctly with Windows 7 64-bit.  I have an ASRock MB with UEFI and it does not have "secure" boot so it works fine!

    Your problem is caused by the UEFI wanting to secure boot, not by Microsoft messing with the MBR!!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”


    No, that's not the problem.  I don't have 'secure boot' enabled, and I am able to boot windows 7 and Linux Mint from the first (SATA0) drive when the second drive is not plugged into SATA1 (plugging it into SATA3 does not cause a problem with booting - but it causes other problems).  It's when I ask the EFI bootloader to load windows, and presumably am now running the windows bootloader that the problems arise.  The windows boot loader sees an MBR on the second SATA1 drive and tries to boot from it.  If I zero out that bootloader, the Windows boot loader does not try to boot from it, and boots Windows 7 successfully from SATA0.  But the next time I try to boot Windows, it's back to trying to boot from the SATA1 MBR - and when I look at that MBR, it's no longer zeroed.  Windows itself has filled in bytes 441-444 with some kind of bootloader signature that then causes Windows to try to boot that MBR in the future.  It's that patching of the MBR that I want to prevent Windows from doing, but I don't know where that's controlled.
    Something in your hardware BIOS configuration or the original method of installing the OS is the root of your problem.  I have 2 motherboards with UEFI and I can set either one to boot from which ever drive I so desire.  Windows boots correctly when the hardware is correctly configured.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Monday, January 28, 2013 3:20 PM
     
     

    Something in your hardware BIOS configuration or the original method of installing the OS is the root of your problem.  I have 2 motherboards with UEFI and I can set either one to boot from which ever drive I so desire.  Windows boots correctly when the hardware is correctly configured.


    The original method of installation I can't speak for - it's an HP OEM setup.  But I'm sure Windows doesn't mind multiple GPT drives.  What it seems to mind is coexisting with an MBR-based drive.  And this has nothing to do with my hardware or BIOS setup.  In fact, if I remove the second (sata1-mbr) drive from my BIOS's boot order, Windows will still not boot with the drive present.  More specifically, it will boot once after I zero out the bootloader from the MBR - and then Windows will patch the MBR so that it will no longer boot.  It's as if windows specifically doesn't want to allow the drive to be there with an MBR.  As though Microsoft thinks they have to prevent me from 'pirating' the XP system on there - which I am not trying to do.  I have no desire to run XP off of the drive - I just want to get the files off of it and leave it around in case I forgot something.  And ultimately, I'd like to preserve the option of putting the old drive back into the old PC and having it still work.

    If there's no way to prevent Windows from messing up the zeroed MBR, then so be it.  I guess I'll have to remove the drive or reformat it with no MBR.  But it stinks that this behavior is undocumented and not preventable.

  • Monday, January 28, 2013 5:22 PM
     
     

    Something in your hardware BIOS configuration or the original method of installing the OS is the root of your problem.  I have 2 motherboards with UEFI and I can set either one to boot from which ever drive I so desire.  Windows boots correctly when the hardware is correctly configured.


    The original method of installation I can't speak for - it's an HP OEM setup.  But I'm sure Windows doesn't mind multiple GPT drives.  What it seems to mind is coexisting with an MBR-based drive.  And this has nothing to do with my hardware or BIOS setup.  In fact, if I remove the second (sata1-mbr) drive from my BIOS's boot order, Windows will still not boot with the drive present.  More specifically, it will boot once after I zero out the bootloader from the MBR - and then Windows will patch the MBR so that it will no longer boot.  It's as if windows specifically doesn't want to allow the drive to be there with an MBR.  As though Microsoft thinks they have to prevent me from 'pirating' the XP system on there - which I am not trying to do.  I have no desire to run XP off of the drive - I just want to get the files off of it and leave it around in case I forgot something.  And ultimately, I'd like to preserve the option of putting the old drive back into the old PC and having it still work.

    If there's no way to prevent Windows from messing up the zeroed MBR, then so be it.  I guess I'll have to remove the drive or reformat it with no MBR.  But it stinks that this behavior is undocumented and not preventable.

    All GPT disks have a legacy MBR so the disk can be recognized by systems that don't recognize GPT disks, so claiming Microsoft has programmed Windows to screw up your system is totally ludicrous.  The MBR allows 32-bit Windows to see that the disk has a GPT partition, but the GPT partition is not accessible by 32-bit Windows.  64-bit Windows can use a GPT disk as a data disk with a legacy BIOS, but UEFI is required to boot from a GPT disk.

    Your problem has something to do with your hardware, not Windows 7!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Monday, January 28, 2013 10:14 PM
     
     

    All GPT disks have a legacy MBR so the disk can be recognized by systems that don't recognize GPT disks, so claiming Microsoft has programmed Windows to screw up your system is totally ludicrous.  The MBR allows 32-bit Windows to see that the disk has a GPT partition, but the GPT partition is not accessible by 32-bit Windows.  64-bit Windows can use a GPT disk as a data disk with a legacy BIOS, but UEFI is required to boot from a GPT disk.

    Your problem has something to do with your hardware, not Windows 7!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

    Okay, it's a little over the top to call it 'intentional'.  But you seem not to hear what's going on on my system.  This is 64-bit Windows 7, and it does boot off of the GPT disk, when I zero the MBR on the old drive (this has nothing to do with the legacy MBR on the GPT drive - I know about that).  Upon (or while) booting, windows changes the MBR on the old drive to mark it 'bootable', and thereafter tries to boot from it again.  I certainly don't know what Windows is trying to accomplish by doing this, but it renders my system no longer bootable to Windows.  I can still boot to Linux, where I can re-zero the MBR on the old drive, which again allows me to boot into Windows 7.  I just want to get windows to STOP REWRITING THE MBR on the secondary drive.  I'm sure it's some kind of automatic 'fix' that windows thinks it's applying - though why it should quietly fix a drive it's not running off of eludes me.  And I fail to see how this could be hardware, since Linux is able to boot with the old drive there regardless of the state of its MBR.  Again, this all happens after my EFI BIOS hands off control to the Windows boot loader.  But yes, the boot loader seems to think that it is running in legacy mode because of the presence of the old drive with a non-GPT/EFI MBR.  If I disable the old SATA1 drive in my BIOS's legacy boot order, Windows still doesn't boot, but it also doesn't try to boot off of the old drive.  In this case, it just gives up and returns to the EFI boot menu - which isn't much help in getting Windows booted...

  • Tuesday, January 29, 2013 11:25 AM
     
     

    And you seem to not understand that the root of your problem is not Windows,

    I have no idea how you developed the problem you have, but Windows is not the cause of your problem!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”

  • Saturday, February 02, 2013 3:01 PM
     
     

    And you seem to not understand that the root of your problem is not Windows,

    I have no idea how you developed the problem you have, but Windows is not the cause of your problem!!

    Sorry, I didn't mean to start a pissing contest.  I don't know whether the 'fault' is Microsoft's or HP's, but the bottom line is that there's something seriously wrong when I can't tell my computer which drive to boot off of.  Even if I tell the BIOS to ignore the 2nd drive, I can't boot Windows with it there - that's bad, whether it's a poorly designed bootloader or one that's designed to find and boot Windows in any of a million different configurations, of which mine confuses it.  What I do know is that it's not just the hardware configuration - Linux has no problem booting with the second drive there, only Windows does.

    Anyway, I bit the bullet and copied the MBR from my primary GPT drive to the secondary MBR drive (effectively, but temporarily, transforming it into an empty GPT drive).  Windows now will boot more than once.  So ultimately, I know I'll be okay once I really wipe the drive.  Wish I didn't have to wipe it, but hey...