UEFI boot strangeness

[Mark R]

I built a bunch of diskless workstations using Giagbyte Z87 mobo, and went to install Ubuntu on them which would boot and run from a USB stick.

The first reboot following installation worked fine. The comps would boot from the sticks, but they would only boot following a cold boot. Not a "restart" from the OS - in that case, the boot would fail after POST with a "Please insert proper boot media" message. This was eventually fixed with "Boot-repair".

This was absolutely consistent regardless of what BIOS settings were chosen (as long as UEFI boot was selected, legacy boot would not work on the installed sticks, at all).

OK. Fair enough, but I needed to do some adjustment with the installer stick. Now here was the weird thing. I would clean shutdown, pull the installeD stick, put the installeR stick in, do some testing, clean shutdown, pull ther installeR stick, and put the installed stick back in. No boot, at all. The stick would not even be detectable as bootable in the BIOS; the configure screen would just say "no selectable boot device".

OK, so I reboot off the installer stick and run boot-repair on the installed stick. Installed stick then boots fine.

Until I transfer the installed stick to the next identical set of hardware. No boot. Stick not seen in the BIOS. However, boot the installer stick, and run boot-repair, and the stick will now boot. In fact, that stick will now boot both motherboards, and after the boot repair, both cold and hot restarts boot fine.

I really have no idea what is going on here. It's like the OS installer is storing something in the BIOS CMOS that authorises a specific stick. A stick will not boot a clone set of hardware, until it is "introduced" to that motherboard by the installer.

I thought this was something to do with secure boot, but the same thing happens with secure boot disabled in the BIOS settings.

Is this deliberate behavior? Is this some weird UEFI boot bug?

 

[VirtualLarry]

I read about something similar, apparently with UEFI boot, the mobo's BIOS actually stores part of the bootloader. So what you are seeing, is apparently normal in this brave new UEFI world.

Edit: I don't know if the UEFI stores part of the bootloader code, or just a pointer to the GUID of the GPT OS boot partition.

As far as I can tell, it's just another unneccesary hassle for PC repair techs.

 

[JoeBleed]

is secure boot enabled or disabled?

I think ubunto supports that. but still, i'd leave it off.

 

[Mark R]

I read about something similar, apparently with UEFI boot, the mobo's BIOS actually stores part of the bootloader. So what you are seeing, is apparently normal in this brave new UEFI world.

Edit: I don't know if the UEFI stores part of the bootloader code, or just a pointer to the GUID of the GPT OS boot partition.

Thanks. That's very interesting. It was driving me crazy and I thought I was going nuts.

The drives are all bit-for-bit copies, with the same partition GUIDs, etc.
So I would expect if it was a simple GUID issue, I would expect it still to work. I guess that the BIOS must store the GUID of the bootable partition in CMOS, and unless the drive matches a GUID already programmed into the BIOS, it won't boot it.