4 ms·

While technically speaking yes, eventually the firmware flash will fail, I'm not sure bad UEFI variables will actually prevent the system from booting, since th

While technically speaking yes, eventually the firmware flash will fail, I'm not sure bad UEFI variables will actually prevent the system from booting, since the rest of firmware should be fine. I've gotten systems to boot with totally borked UEFI flash space. It is being nitpicky on my part, but I think we're reaching the point where these machines could be expected to last long enough for SSD weardown to become a real issue, even with current flash tech. While this has theoretically been a problem for the past 5 years now, it's a bit disappointing to learn that now you can't use an external drive in the event of the (irreplaceable) internal drive failing.

marcan_42 6y ago
That depends on the implementation. For example, I've seen many PCs exhibit a behavior where after a major hardware change, usually CPU or RAM, the system boots, shuts down, then boots again automatically. Presumably after discovering the change it wrote some variables describing it, then rebooted. Without the ability to persist that information, I would expect it to loop forever.
floatboth 6y ago
Raw EDK2 doesn't really need variables at all (in fact if you use it as a coreboot payload, persistentce is not implemented whatsoever, at least as of.. some time ago). Various crap bolted on by AMI and the OEMs… well, YMMV – remember these laptops where someone did rm -rf with mounted efivarfs on Linux and that bricked it because it just refused to boot without the variables :D
- spijdar 6y ago
  I can believe that sadly :/ UEFI implementations range from pretty good to absolute crap. My newest Dell has at least been mostly decent, but an older Dell has so many issues with the firmware, it's unbelievable. Not that it (worn out flash) is gonna be a problem in practice, anyway. Neither will the M1's inability to boot without the internal drive. Like Marcan said, it's not really likely to die in realistic use within a pretty long lifespan, I just find these sorts of shortcomings/regressions ... disappointing. I get the various reasons why, it's just annoying.
easton 6y ago
A counterpoint would be around 2012-14 (can’t remember exactly), when secure boot was hitting the mainstream, the Ubuntu installer (and systemd) didn’t know that UEFI anything was stored on the internal disk and would wipe it out, causing many machines to hard brick (which then made Lenovo say “uh, we don’t support Linux, tough”, which wasn’t cool). https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402

marcan_42 6y ago

That depends on the implementation. For example, I've seen many PCs exhibit a behavior where after a major hardware change, usually CPU or RAM, the system boots, shuts down, then boots again automatically. Presumably after discovering the change it wrote some variables describing it, then rebooted. Without the ability to persist that information, I would expect it to loop forever.

floatboth 6y ago

Raw EDK2 doesn't really need variables at all (in fact if you use it as a coreboot payload, persistentce is not implemented whatsoever, at least as of.. some time ago). Various crap bolted on by AMI and the OEMs… well, YMMV – remember these laptops where someone did rm -rf with mounted efivarfs on Linux and that bricked it because it just refused to boot without the variables :D

spijdar 6y ago
I can believe that sadly :/ UEFI implementations range from pretty good to absolute crap. My newest Dell has at least been mostly decent, but an older Dell has so many issues with the firmware, it's unbelievable. Not that it (worn out flash) is gonna be a problem in practice, anyway. Neither will the M1's inability to boot without the internal drive. Like Marcan said, it's not really likely to die in realistic use within a pretty long lifespan, I just find these sorts of shortcomings/regressions ... disappointing. I get the various reasons why, it's just annoying.

easton 6y ago

A counterpoint would be around 2012-14 (can’t remember exactly), when secure boot was hitting the mainstream, the Ubuntu installer (and systemd) didn’t know that UEFI anything was stored on the internal disk and would wipe it out, causing many machines to hard brick (which then made Lenovo say “uh, we don’t support Linux, tough”, which wasn’t cool). https://github.com/systemd/systemd/issues/2402 https://github.com/systemd/systemd/issues/2402