Comment by csdvrx | Hacker News Reader

Comment by csdvrx | Hacker News Reader

Parent Full thread

The UEFI entries are just regular EFI variables, except they use a special GUID: 8BE4DF61-93CA-11D2-AA0D-00E098032B8C cf https://stackoverflow.com/questions/67395528/ and the actual description in https://github.com/erikberglund/AppleNVRAM/blob/master/EFI/8... with examples on how to access them from an UEFI shell on https://oofhours.com/2019/09/02/geeking-out-with-uefi/

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!

> 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

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.

There's a pretty decent chance nobody else is actually trying. The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition.

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?

> The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition.

> 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?

The Windows versions I installed for testing were non-OEM versions. They still behaved as expected.

Notably, Windows didn't just know about all the standard UEFI variables, but also about a non-standard one that I added for testing. This means that there definitely is a way to ask for the list of variables so that the UEFI accepts it (sadly, reverse engineering that is a pain), and that the Linux kernel is most likely the place where an actual fix has to happen.

Of course, yes, at the end of the day, the root cause is a specification non-conformity in the UEFI itself.

> (sadly, reverse engineering that is a pain), and that the Linux kernel is most likely the place where an actual fix has to happen.

You did most of the work already, and it's super interesting (or at least, it's the kind of things I find super interesting lol) so you may want to finish fixing the issue?

It's funny how outside RU.EFI, there're no nice tools for such a basic features as tweaking UEFI variables, so if you are into this kind of things, you may also be interested by writing a better efibootmgr: many people (including myself, and now you) are dissatisfied by the issues it can create: https://old.reddit.com/r/archlinux/comments/18j6o7x/rfc_what...

>There's a pretty decent chance nobody else is actually trying. The only other OS getting installed is Windows, and that's probably coming straight from a disk image or a recovery partition.

From TFA: "Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect."

> From TFA: "Note: At this point, I checked that Windows and various other UEFI tools are able to read the variables just fine, so Linux’ output is confirmed to be incorrect."

UEFI is a bit complicated and it's well known the EDD3 specifications can cause issues to efibootmgr, for example on Dell https://github.com/rhboot/efibootmgr/issues/86

I just think it'd be nicer to have a multiplatform way to tweak UEFI boot variable, so you can fiddle with your UEFI variables from either Linux or Windows without having to actually go into the UEFI shell or use a PE32 like RU.EFI : https://ruexe.blogspot.com/

Hhhhh 8uhga

> 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?

I've never really seen a single example of this. Could you provide some?

My ASUS UX305UA's touchpad stopped working when I removed the windows partition.

Reply on news.ycombinator.com