In this blog I document my journey in learning the UEFI boot process and discover that not all laptop firmware implement the UEFI standard correctly or how you’d expect.
I’m curious if anyone else has had trouble getting laptops specifically to retain their UEFI BootOrder and if anyone else here has seen behavior like this on devices recently.
Not quite the same issue, but similar in the sense that it was caused by a UEFI that didn’t conform to spec.
I have an HP laptop that I installed Debian on, and it would never actually boot to grub even though I checked the boot entries several times over. You could open the settings and choose the boot entry manually, so it’s not like it was a problem with the OS or with grub. Turned out, this model was hard coded to only allow a boot entry named “Windows Boot Manager” to be loaded by default. I used efibootmgr to rename the debian entry and it booted into grub straight away.
Turned out, this model was hard coded to only allow a boot entry named “Windows Boot Manager” to be loaded by default.
Holy moly that’s absolutely shocking. Yeah I didn’t quite realize how scuffed various UEFI implementations were until I encountered this issue and started looking around. Wild.
Imagine if you remane your install to Windows Boot Manager
Edit: I’m pretty sure you can actually do that with efibootmgr
Guess what? My HP 2000 Notebook PC laptop (not my daliy driver) decides it’s a great idea to prefer “OS boot manager” (WBM), over “Linux Boot Manager” (sysd boot). The funny thing is that renaming the “Microsoft” folder in the ESP to something like “Macrosaft” fucking works. My daily driver lets me just set it in the UEFI BIOS screen.
That’s very weird, my experience with HP’s (Probook) UEFI implementation is that it actually worked quite well compared to other laptops. If even featured a basic editor to insert a specific path to an alternative bootloader in case you couldn’t figure out efibootmgr.
I really wish more laptop manufacturers would offer coreboot firmware instead of firmware made by shady proprietary firmware vendors based in China.
UEFI has a fallback bootloader (\efi\boot\bootx64.efi) that will usually work. That’s also why Windows will put a bootloader there, and why some devices don’t boot Grub anymore after Windows updates itself. You don’t even need to create a boot entry in NVRAM most of the time if you use that path.
Many times, UEFI implementations are buggy as hell. If your boot order settings don’t work, reset the settings to factory defaults and try again. I’ve had to deal with NVRAM corruption a bunch of times and manually fixing them just isn’t worth the headache.
Also, make sure your GPT partition is actually up to spec. When you don’t have the right GUIDs/flags on a partition, firmware will be quick to fall into some kind of quirks mode that just doesn’t work right. I can see why they do it, “the disk is corrupt but let’s try to boot Windows anyway” isn’t a bad way to approach that kind of fail state. As if the average consumer will know how to apply C12A7328-F81F-11D2-BA4B-00A0C93EC93B to their EFI system partition, they just want to play Candy Crush!
Some older devices have an annoying issue where their UEFI implementation is 32 bit, despite having a normal amd64 CPU. In those cases, you’re going to need the x86/ia32 path and special x86 bootloaders or the computer simply won’t boot. You can boot 64 bit operating systems from those, but moet package managers only ship amd64 versions of their loaders.
