UEFI hard drive boot order and boot menu are completely ignored

I have a bit of a puzzle, and I don't know whether to blame the motherboard maker, Microsoft, or -- this is a really distant third choice, obviously -- myself. (That being said, UEFIs and GPT drives are new to me, so that distant third choice might not be as distant as I'd hoped.)

I recently set up a new computer for a friend. It has an ASRock z97 Extreme4 motherboard. I managed to install Windows 7 Pro x64 in UEFI mode on a "single-partition" 4TB GPT-format drive. So far, so good.

Minimal downtime and minimal data loss are my friend's top priorities. Because we've had bad experiences with both hardware and software RAID 1 (mirroring) in the past, RAID was out and cloning was in. (Over ten years, we had close to zero downtime and data loss with the cloning system on his previous XP system.)

I installed three mobile racks in the chassis. The top one is for the 4TB "original system" drive. The middle one is for a 4TB "resident clone" of the original system drive. The bottom one is for two additional 4TB "swapped clones" that will be cloned to on alternate days and stored in a waterproof, fireproof data safe when not in use. The "resident clone" will stay in the computer and, in addition to periodically being recloned to, will have data files mirrored to it from the original system drive in close to real time. So far, so good.

The top mobile rack is connected to SATA port 0, the middle mobile rack is connected to SATA port 1, and the bottom mobile rack is connected to SATA port 2, so:

• SATA port 0 = top mobile rack = original system drive
• SATA port 1 = middle mobile rack = resident clone drive
• SATA port 2 = bottom mobile rack = swapped clone drives

In the UEFI I set the hard drive boot order to:

• AHCI port 0 = SATA port 0 = top mobile rack = original system drive
• AHCI port 1 = SATA port 1 = middle mobile rack = resident clone drive
• AHCI port 2 = SATA port 2 = bottom mobile rack = swapped clone drives

(Am I right in assuming that AHCI ports are statically assigned to physical SATA ports? Or are they dynamically assigned at startup according to some scheme that I haven't been able to determine? But apart from that lingering doubt, so far, so good.)

The thing is, you want to test a clone's bootability from time to time, and that's where the puzzle comes in.

If we always boot to the original system drive, in the top rack (SATA port 0), no problem. We can start the system with all of the drives powered on, and the system will continue to boot from the correct drive time after time.

If we try to test a clone's bootability by shutting down, leaving the clone in its original mobile rack, powering off the other drives, and restarting, still no problem (for the moment). The system will boot to the clone.

The problem is, once we've booted from a different drive connected to a different port, the system wants to continue booting from that drive and that port. It doesn't matter what the UEFI hard drive boot order is or (if you manually trigger the boot menu at startup) what AHCI port we choose, the system will try to boot from the same drive and port it booted from the previous time.

For example, if the resident clone (port 1) is left powered on after its bootability is tested, and the original system drive (port 0) is powered back on, and the system is started, the system will boot to the clone. And if only the original system drive (port 0) is powered on at startup, the system won't find a bootable drive anywhere. (To reset the system after it fixates on booting from the wrong drive and port, you apparently have to cut mains power to the chassis.)

This is my first experience with a UEFI system, but this behavior strikes me as fishy and I suspect that ASRock's UEFI is at fault. Shouldn't the hard drive boot order and manual boot menu actually do something? Is the UEFI immediately handing over boot control to Windows and allowing Windows to decide what drive and port to boot from? And if so, why bother having a hard drive boot order or offering a boot menu? For Linux? Do the hard drive boot order and manual boot menu only work with MBR drives, not GPT drives? And was I supposed to know that?

For the time being, there is a relatively easy workaround (for us, only because we have mobile racks):

• When we want to test a clone's bootability, we have to physically swap it to the top mobile rack (port 0) and start the computer with only that drive powered on.
  
  
• When we want to go back to booting to the original system drive after the test, we have to physically swap it back to the top mobile rack (port 0) and start the computer with only that drive powered on.
  
  
• Otherwise, so long as we want to continue to boot to the original system drive, it's fine to start the computer with the other drives powered on -- the system will continue to boot from the original system drive each time.

(People without mobile racks would not be so lucky. To test their clones' bootability, they would have to open the chassis and start changing SATA cable connections...)

So, what's the verdict? Does ASRock's UEFI have a major bug? Or is this inability to choose a boot drive through the UEFI the result of a Windows or GPT or UEFI design choice? Or have I done something wrong? Let 'er rip, guys and gals. After the hair-pulling hassle and humongous time-suck I went through nailing down what was going on, I can take just about anything.

Oh, and I almost forgot: of course I've been in touch with ASRock tech support. They told me to connect the mobile racks to SATA ports 0, 1, and 2 instead of the original 2, 3, and 4. It made no difference whatsoever.

Anyway, if anyone has any insights into this problem, I'd be very grateful to hear them. Thanks!

Thanks so much for responding. Sorry the post was long; it was a tough problem to diagnose and difficult to describe concisely.

Yes, the gist of it is that when you start the computer, it ignores the hard drive boot order you've set in the UEFI/BIOS and, if you trigger the boot menu, it ignores the boot drive you manually select there.

If you always boot from the same drive and SATA port -- the first drive in the hard drive boot order, connected to the SATA port with the lowest number -- no problem.

If you shut down and power off the first drive, the computer will boot from the second drive in the hard drive boot order, connected to SATA port with the second lowest number -- so still, no problem.

But if you shut down, power the original drive back on, and restart without intervening, the computer will continue to boot from the second drive, even though the first drive in the UEFI's hard drive boot order is powered on.

And if you restart, trigger the boot menu, and manually tell the computer to boot from the first drive, it will continue to boot from the second drive.

And if you shut down, power off the second drive while leaving the first drive powered on, and start up without intervening, the computer won't find a drive to boot to at all, even though the first drive in the UEFI's HD boot order is present.

And if you restart, trigger the boot menu, and manually select the first drive, the computer still won't find a drive to boot to.

It seems that something other that the UEFI/BIOS HD boot order and boot menu is determining what drive is booted to. Maybe the computer follows the boot order on the very first boot alone, or maybe it just boots to the drive on the SATA port with the lowest number. After that, if the previous drive is unavailable (powered off), maybe it boots to the drive on the next available SATA port. But once it does that, it gets "fixated" on that SATA port and won't boot to a SATA port with a lower number until the UEFI is "reset" by turning off the computer's power supply. It's a bizarre and frustrating problem -- at least with our set-up, where we need to periodically test whether a clone drive is bootable. To my mind, the UEFI/BIOS boot order and the boot menu should actually do what they are supposed to do...
Having bricked a couple/few devices in the past, I generally avoid firmware updates that are not documented as fixing a problem I am experiencing. To my knowledge, there is one UEFI update available for the ASRock z97 Extreme4, but it is documented as addressing other issues (overclocking, I think), and ASRock tech support did not suggest that I install it.

We toyed with using SSD system drives and HD data drives when designing the system, but nixed it for now due to greater expense, greater complexity, less certain lifespan, and less certain outcome of cloning operations.

I doubt that the size of the HDs is relevant to the problem, though the fact that they are GPT-format drive might be.

Anyway, I appreciate your getting back to me. Although I still suspect this is an ASRock UEFI/BIOS bug, maybe someone who's experienced (and hopefully solved) a similar problem will stumble upon this thread and chime in. All the best.

I seem to be having pretty much the same problem with my Biostar TA990FXE..I am unable to get my SSD to boot no matter what order I put SSD drive in..So far I have been able to make since of it all. No matter what drive I select the Sata drive boots..Even after removing the Sata drive. The SSD drive will no longer boot. I originally installed the SSD with my OS and it worked fine, Then I plugged in my Sata drive and tried to boot. From that time on the Crucial SSD drive will no longer boot.

PCMartin said:

I have a bit of a puzzle, and I don't know whether to blame the motherboard maker, Microsoft, or -- this is a really distant third choice, obviously -- myself. (That being said, UEFIs and GPT drives are new to me, so that distant third choice might not be as distant as I'd hoped.)

I recently set up a new computer for a friend. It has an ASRock z97 Extreme4 motherboard. I managed to install Windows 7 Pro x64 in UEFI mode on a "single-partition" 4TB GPT-format drive. So far, so good.

Minimal downtime and minimal data loss are my friend's top priorities. Because we've had bad experiences with both hardware and software RAID 1 (mirroring) in the past, RAID was out and cloning was in. (Over ten years, we had close to zero downtime and data loss with the cloning system on his previous XP system.)

I installed three mobile racks in the chassis. The top one is for the 4TB "original system" drive. The middle one is for a 4TB "resident clone" of the original system drive. The bottom one is for two additional 4TB "swapped clones" that will be cloned to on alternate days and stored in a waterproof, fireproof data safe when not in use. The "resident clone" will stay in the computer and, in addition to periodically being recloned to, will have data files mirrored to it from the original system drive in close to real time. So far, so good.

The top mobile rack is connected to SATA port 0, the middle mobile rack is connected to SATA port 1, and the bottom mobile rack is connected to SATA port 2, so:

• SATA port 0 = top mobile rack = original system drive
• SATA port 1 = middle mobile rack = resident clone drive
• SATA port 2 = bottom mobile rack = swapped clone drives

In the UEFI I set the hard drive boot order to:

• AHCI port 0 = SATA port 0 = top mobile rack = original system drive
• AHCI port 1 = SATA port 1 = middle mobile rack = resident clone drive
• AHCI port 2 = SATA port 2 = bottom mobile rack = swapped clone drives

(Am I right in assuming that AHCI ports are statically assigned to physical SATA ports? Or are they dynamically assigned at startup according to some scheme that I haven't been able to determine? But apart from that lingering doubt, so far, so good.)

The thing is, you want to test a clone's bootability from time to time, and that's where the puzzle comes in.

If we always boot to the original system drive, in the top rack (SATA port 0), no problem. We can start the system with all of the drives powered on, and the system will continue to boot from the correct drive time after time.

If we try to test a clone's bootability by shutting down, leaving the clone in its original mobile rack, powering off the other drives, and restarting, still no problem (for the moment). The system will boot to the clone.

The problem is, once we've booted from a different drive connected to a different port, the system wants to continue booting from that drive and that port. It doesn't matter what the UEFI hard drive boot order is or (if you manually trigger the boot menu at startup) what AHCI port we choose, the system will try to boot from the same drive and port it booted from the previous time.

For example, if the resident clone (port 1) is left powered on after its bootability is tested, and the original system drive (port 0) is powered back on, and the system is started, the system will boot to the clone. And if only the original system drive (port 0) is powered on at startup, the system won't find a bootable drive anywhere. (To reset the system after it fixates on booting from the wrong drive and port, you apparently have to cut mains power to the chassis.)

This is my first experience with a UEFI system, but this behavior strikes me as fishy and I suspect that ASRock's UEFI is at fault. Shouldn't the hard drive boot order and manual boot menu actually do something? Is the UEFI immediately handing over boot control to Windows and allowing Windows to decide what drive and port to boot from? And if so, why bother having a hard drive boot order or offering a boot menu? For Linux? Do the hard drive boot order and manual boot menu only work with MBR drives, not GPT drives? And was I supposed to know that?

For the time being, there is a relatively easy workaround (for us, only because we have mobile racks):

• When we want to test a clone's bootability, we have to physically swap it to the top mobile rack (port 0) and start the computer with only that drive powered on.
  
  
• When we want to go back to booting to the original system drive after the test, we have to physically swap it back to the top mobile rack (port 0) and start the computer with only that drive powered on.
  
  
• Otherwise, so long as we want to continue to boot to the original system drive, it's fine to start the computer with the other drives powered on -- the system will continue to boot from the original system drive each time.

(People without mobile racks would not be so lucky. To test their clones' bootability, they would have to open the chassis and start changing SATA cable connections...)

So, what's the verdict? Does ASRock's UEFI have a major bug? Or is this inability to choose a boot drive through the UEFI the result of a Windows or GPT or UEFI design choice? Or have I done something wrong? Let 'er rip, guys and gals. After the hair-pulling hassle and humongous time-suck I went through nailing down what was going on, I can take just about anything.

Oh, and I almost forgot: of course I've been in touch with ASRock tech support. They told me to connect the mobile racks to SATA ports 0, 1, and 2 instead of the original 2, 3, and 4. It made no difference whatsoever.

Anyway, if anyone has any insights into this problem, I'd be very grateful to hear them. Thanks!

Hello PCMARTIN, I have replied with a full quote of your original article becasue here I am in June 2015 with two ASROCK B85M PRO4 motherboards with exactly the same problem that you experienced back in 2014 with no solutions forthcoming from ASROCK.

I also use Mobile Rack type removable hard disc caddies and have done so for over 20 years now, it's the only way to go especially in a world of hackers and virus infections not to mention Windows corruptions although Windows 7 is the best version yet.

Your article is very well written and I've come across this forum is desperation after many hair pulling hours trying every permutation imaginable, I've never experienced anything like it before but you are right there seems to be some secret cache of Hard Disc serial numbers that the ASROCK UEFI keeps hidden away.

I had to prove the Hard Discs in another system with a different motherboard to prove that the discs themselves were okay.

Do you or does anyone else have an update to this bizarre problem with ASROCK motherboards?

Very best regards and many thanks for your origianl article.

I have the AsRock D1800B-ITX motherboard so my problem is similar, although not identical. I'm running Linux but the UEFI firmware works the same for any OS so my findings are applicable to Windows as well.

When you "clone" a hard drive, the UUIDs of the GPT partitions get cloned as well. This makes them no longer "unique" IDs, so the firmware gets a little confused. For example, you can dump what the UEFI knows about your EFI partitions with the Linux command "efibootmgr":

Code:

$ sudo efibootmgr -v
BootCurrent: 0002
Timeout: 2 seconds
BootOrder: 0004,0000,0002,0003
Boot0000* CentOS_b      HD(1,800,34000,d41f9a56-5a05-446d-b13c-6c962a6b007f)File(\EFI\centos\shim.efi)
Boot0002* CentOS_a      HD(1,800,34000,d41f9a56-5a05-446d-b13c-6c962a6b007f)File(\EFI\centos\shim.efi)
Boot0003* USB   BIOS(5,0,00)..GO..NO........g.G.e.n.e.r.i.c.-.S.D./.M.M.C. .1...0.0...................A.....................................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6.......BO..NO........o.G.e.n.e.r.i.c.-.C.o.m.p.a.c.t. .F.l.a.s.h. .1...0.1...................A.............................................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6.......BO..NO........o.G.e.n.e.r.i.c.-.S.M./.x.D.-.P.i.c.t.u.r.e. .1...0.2...................A.............................................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6.......BO..NO........o.G.e.n.e.r.i.c.-.M.S./.M.S.-.P.r.o. .1...0.3...................A.............................................Gd-.;.A..MQ..L.0.5.8.F.6.3.6.4.6.4.7.6.......BO
Boot0004* Hard Drive    BIOS(2,0,00)..GO..NO........o.W.D.C. .W.D.1.0.J.P.V.X.-.0.0.J.C.3.T.0...................A..........................>..Gd-.;.A..MQ..L. . . . .W. .-.D.X.W.1.Q.9.E.J.3.L.D.2.Z.......BO

The "CentOS" boot entries all have the same UUID (d41f9a56-5a05-446d-b13c-6c962a6b007f) stored in the UEFI's brains. I know these are partition UUIDs because I can dump all of them in the system with blkid:

Code:

$ sudo blkid
/dev/sda1: SEC_TYPE="msdos" UUID="B964-981F" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="d41f9a56-5a05-446d-b13c-6c962a6b007f"
/dev/sdb1: SEC_TYPE="msdos" UUID="7940-3C69" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="d41f9a56-5a05-446d-b13c-6c962a6b007f"

Since sda and sdb are clones of each other, this makes sense. Now from the above we might think the UEFI firmware does not store the physical port of the boot drive, since the listing are identical for CentOS_a and CentOS_b. But there must be more being stored away as the experiments in previous posts and mine present.

In my case, pressing F11 to bring up the "boot menu" allows me to manually (every time) boot from sdb when sda is missing. But on the next boot it will revert to the error message of death ("please insert bootable media and reboot bla bla") when sda missing. (There are only 2 SATA ports on the D1800B).

There is a command that will change the partition UUID to a new random one:

Code:

$ sgdisk -G /dev/sdb

However, that will mean the drives are no longer clones and probably cannot be swapped around to different SATA ports. I plan to experiment more with this approach and see if it helps or hurts the situation. You can boot to the gparted live CD GParted -- Live CD/USB/PXE/HD and try this on your clones also to see if it helps the situation.

My current guess is AsRock didn't plan on seeing duplicate partition UUIDs within the same system.