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...
Comments
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.
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...