We ended up writing some hilariously crappy workarounds for Linux to prevent this kind of thing, where firmware fails to boot if the UEFI variable store is too full. We check whether the write would leave under 5KB of free space (as reported by the firmware), and refuse the write if it would. Easy! Except some firmware would never actually increase the available space count if a variable was deleted, so after a while we'd just never be able to write any more variables

I can't remember how I figured this out, but the affected machines would trigger garbage collection if we tried to create a variable bigger than the available space, so Linux just tries to create a giant variable and then deletes it again to force the firmware to actually update the free space counter

Fucking computers, man

@mjg59 Fucking UEFI. The ring -1 (or is it -42 now? does anyone even know or care?) shit nobody asked for.

@dalias @mjg59 UEFI and ACPI solve the problem of booting the same image on a wide variety of machines. From a distro point of view, that's a huge win. Whether it is worth the huge number of tradeoffs is another question.

@alwayscurious @mjg59 Device tree solves that problem. UEFI and ACPI both address a much larger-scope problem (which a lot of us don't want) of having a persistent layer under your trusted OS that you also have to trust, that continues execution after control was supposed to be passed to the OS, and that the OS is forced to interact with to access important functionality.

@dalias @mjg59 Device tree would be a solution if all of the board-specific code reached mainline, but it doesn't. See @mjg59's commentary on the subject.

@alwayscurious @mjg59 Sorry, I wasn't clear. I don't mean it's a way you can do things right now. I mean the problem of "booting same image on diverse hardware" is a much smaller-scope problem domain than what UEFI and ACPI do ("abstraction layer/runtime under your trusted OS kernel"). And some of us are very very unhappy that we're expected to accept the latter in order to get the former.

@dalias @mjg59 I'm one of them, but look at the situation in the Arm world and how many people are stuck running ancient kernels.

@alwayscurious @mjg59 This is largely the fault of Linux being a monolithic mess. Nobody would much care that the board-hardware-support kernel was ancient if the actual OS (filesystems, syscalls, networking, etc.) and non-board specific hardware support were separate layers that could be upgraded independently.