The main issue with fixing it properly is that I'd most likely have to reverse engineer the Windows kernel or the UEFI firmware itself (note to self: I haven't yet checked whether any of the *BSDs can read EFI variables in general and on this hardware in particular) to figure out where the request is going wrong/what Windows is doing different.
It's not impossible, given that one can unpack the UEFI PI firmware image into all the separate modules, but going through them to figure out where variable management is implemented will still take me a few weeks at least (not due to any particular challenge, it's just consuming a lot of time that I don't have right now).
Good news: FreeBSD is able to read the whole variable list.
Bad news: I just wiped my test drive with all the in-progress kernel patches by accident.
Grab the memstick image from here: https://download.freebsd.org/releases/ISO-IMAGES/14.0/
Uncompress it, and dd it to your USB drive. (dd if=FreeBSD-14.0-RELEASE-amd64-memstick.img of=/dev/sdb bs=1m conv=sync, assuming sdb is your usb stick..)
This could happen either through somehow getting logging from the Windows end, or somehow changing the UEFI to be one you control and logging there, or finding a different BIOS/OS that can read the vars and getting it to log its work.
Before doing such complicated things, have you tried with RU.EFI?
I'd love a footnote explaining how you did this.
Had there been any more than one possible type of chip and more than three of these similar looking chips on the [accessible part of the] motherboard, I'd probably still be sitting here trying to figure out what to do.
In any case, I'll try and add it to the blog post once I figure out how to do footnotes. :^)
Someone clearly thought that was a good idea, and I wouldn't be surprised if they thought the same of the bloated monstrosity that is UEFI. "Let's make the setup an EFI application" sounds like a reasonable argument, but they don't realise that it's a very important application, one which should be accessible under all circumstances short of having the BIOS erased.[1]
We're approaching 10 years since this happened: https://news.ycombinator.com/item?id=5139055
And almost 8 years since this: https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=10999335
[1] Most if not all BIOSes on EEPROM (late 90s onwards) before UEFI had "boot block recovery" which would automatically detect if they were corrupt and attempt to recover by flashing from a specially formatted floppy disk.
Profoundly annoying, but, thankfully not commonplace and those couple times it's happened to me I've been in the return window, so, back they went. I figure that's as big of an FU as I can muster, the OEM dealing with a higher than normal return rate.
Last time it was a HP laptop running a god aweful bloatware infested version of windows 8.1, never again.
These variables are what `efibootmgr` lists and can change on Linux, what `bcdedit /enum firmware` lists on Windows, and what GetSetVariable can manipulate on Windows cf https://github.com/ProSlatisa/GetSetVariable/tree/master/Var...
Ultimately, each are OS-specific solutions, while it would be interesting to make a crossover between efibootmgr and GetSetVariable (and that C program) to create a tool working on both Linux and Windows with cosmopolitan to restore/hack 8BE4DF61-93CA-11D2-AA0D-00E098032B8C variables, because a quick search on that magic shows some people have uploaded their efivar to github for other models so it must be a common issue!
I seems that nobody except for Linux (for some not yet determined reason) is having issues with retrieving EFI variables on this hardware, and one could potentially classify this as a bug in `efibootmgr` as well (due to how it handles creating the new entry in unknown conditions).
In either case, Linux is the only thing affected by this, so in real-world setups Linux is going to be the only boot option that is available while the boot menu is in a broken state.
Especially in laptops, a lot of hardware / firmware issues are simply "solved" by baking a fix into the pre-installed Windows version. It's a solution for 99% of users, so why bother spending time looking into the root cause?
As it was advertised as OpenSUSE compatible (and even came with stickers and such) first one or two times they made a fuss about it, but after that they replaced pretty much on the demand.
I wonder if that was also related to the issue article was mentioning. But such design lasting for multiple years?
Consider 'I got caught' and 'I got hit'.
I remember the opposite problem being the case on the T420 BIOS. If you didn't set a newly added entry as NextBoot, it'd just disappear after reboot.
The BIOS never stood a chance. Maybe it was self deleting to hide evidence.
Thanks, I'm here all night.
