Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: