UEFI hard drive boot order and boot menu are completely ignored

[PCMartin]

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!

 

[ICIT2LOL]

Hello and welcome PCMartin. To be absolutely honest your thread is very detailed and I really don't understand a lot of it but the gist is the boot order does not follow the settings in the BIOS??

Did AsRock suggest a BIOS update? if not and if you are not game to go without their say so then contact them again as it sound like it is the most part of the problem.

Personally I am not a fan of large capacity drives and prefer to have smaller because of drive crashing and therefore less data is lost. But having said that you might have need for that amount of space I suppose.

My choice would be an SSD for booting and the large drives for data etc etc

 

[PCMartin]

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.

 

[ICIT2LOL]

Yes absolutely you are right re the BIOS on that board and by the by I am not a fan of AsRock as I had a mate who had no end of problems with that brand when he did his Ivy build and went to Asus - which I prefer (I also like Gigabyte). So either you can get back to AsRock and get a replacement as I am not sure how one fixes that BIOS problem other than an update - either backwards (an option) or the latest.

Now lifespan for SSD's I think people tend to overrate them not lasting as long as a spinner. To me at least - any device whether it uses moving or non moving parts wears out eventually and the SSD's these days are far better made than when they first came in. I know a lot depends on what you use the drive for and the SSD's the faster they are generally wear faster but I think you would be extremely unlucky for one to last less than five years. It is a bit like a car use it a lot and / or drive it hard / don't get it serviced regularly then of course it will wear out faster.

I still am not a fan of the large drives for reasons I outlined before and if I had a lot of data on a drive then losing it in one fell swoop would really annoy me (I did lose a 1TB a long time ago and vowed never again). But it is a personal choice I suppose and one can always back up the really important stuff onto externals.

But back to that BIOS it is up the proverbial creek and I would be getting a replacement if I could not get satisfaction from AsRock.
Good luck and keep us posted re what happens

 

[rvcjew]

sounds like the bios is confused which drive to boot from since they are the same model even though they are on different sata channels yeah thats odd, subbed to see how this ends up. where the drives ever in a spanned RAID 1 array? EDIT: also what did you do the initial clone with, and did you clone it with data or also the same disk signature too?

 

[pittly]

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.

 

[ICIT2LOL]

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.

Hello and welcome pittly now have you recently updated the BIOS? can you look and let us know what version you have please?

Now if you are going to update the BIOS be aware that it can possibly brick the motherboard as you can see from this link
TA990FXE :: Motherboard :: BIOSTAR I would if I were you contact Biostar before I did anything.
I am thinking that the BIOS is either way out of date or faulty because it is not using the settings you put in ie the boot source sequence.
Personally I am not that familiar with the Biostar brand and I use Asus and Gigabyte boards which offer a secondary BIOS "back up" should one update and wreck the first one so please be careful what you do without finding out for definite first..

 

[essenbe]

I have a UEFI capable board, but have never used UEFI. As far as I am aware, in your boot order in bios, you will have a listing of your hard drives and the another listing of the same drives with UEFI in front of the name. UEFI has secure boot and you have to select the UEFI. Each disk is required to have a unique identifier in the UEFI and Partition GUID table on that partition in order for it to boot. So, when you clone a drive, you have 2 drives with the same identifier, which in theory at least, will make it not boot at all. You can clone the data on them though. This will explain it better than I can. http://www.sevenforums.com/tutorial...e-firmware-interface-install-windows-7-a.html

 

[Gantos22]

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.

 

[blackskyatnight]

I want to get to the bottom of this too

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":

$ 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:

$ 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:

$ 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.

 

[blackskyatnight]

Finally got it

Ok, I can confirm the original poster's finding that the AsRock boot order GUI screen is bunk. Although it appears to let you arrange the boot order, it doesn't wind up sticking. I used the linux efibootmgr command to set the order that I wanted:

# efibootmgr -o 0000,0002,0003,0004
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0002,0003,0004
Boot0000* CentOS_b
Boot0002* CentOS_a
Boot0003* USB
Boot0004* Hard Drive

After setting it this way I followed the original poster's advice and performed a *COMPLETE* power off (pull the power cord, try to turn on, wait a minute). And now everything is perfection. I can place either disk in either SATA port at get perfect booting every time without having to press the F11 option at boot.

It turns out no matter which drive is in what port, it always reports a "BootCurrent" of 0000, meaning I probably don't need BOOT0002 in the boot sequence since the hard drives are clones of each other (identical UUIDs). But it's working so great now I don't want to mess with it.

 

[rvcjew]

Glad you found out how to do it and shame on ASrock for not addressing this kind of thing. Hope they put out an update to fix this.