That’s an interesting failure mode. Is there any reason why the manufacturer didn’t consider that boot entries can be created and destroyed by the customer?
PC firmware is a mess because pre-UEFI boot behavior was mostly a custom rather than a defined standard, but then standards got added over time. That basically adds up to the success target for most manufacturers being "does it boot Windows?" - once it did that, then they were done.
UEFI was supposed to make this better, I guess, by specifying everything in several hundred (if not thousand) pages, but it added a lot of complexity (esp. with Secure Boot and such). It doesn't help that most end-user visible firmware functions are rarely accessed, so as long as it does boot Windows in the manufacturer supplied hardware configuration, most people won't care or even know of any issues.
PC firmware bugs aren't really anything new. When ACPI first came out in the late 90's/early 00's, initial implementations were buggy - so buggy that I think starting from Vista, it won't boot if the BIOS date is before 2000. Linux source code has numerous BIOS workarounds in it.
El Torito, the standard enabling bootable CDs, also had problems when it first came out.
I had a Haswell-era MiniITX Gigabyte motherboard that had a similar issue. Installing the Clover/Chameleon and booting into macOS messed up the EFI and the system wouldn't boot. Went through two motherboards before I bought a different brand.
Comments
Related to killing EFI variables in a way the UEFI didn't expect I bet - would happen when boot loader is installed and boot entries set possibly.
That’s an interesting failure mode. Is there any reason why the manufacturer didn’t consider that boot entries can be created and destroyed by the customer?
PC firmware is a mess because pre-UEFI boot behavior was mostly a custom rather than a defined standard, but then standards got added over time. That basically adds up to the success target for most manufacturers being "does it boot Windows?" - once it did that, then they were done.
UEFI was supposed to make this better, I guess, by specifying everything in several hundred (if not thousand) pages, but it added a lot of complexity (esp. with Secure Boot and such). It doesn't help that most end-user visible firmware functions are rarely accessed, so as long as it does boot Windows in the manufacturer supplied hardware configuration, most people won't care or even know of any issues.
PC firmware bugs aren't really anything new. When ACPI first came out in the late 90's/early 00's, initial implementations were buggy - so buggy that I think starting from Vista, it won't boot if the BIOS date is before 2000. Linux source code has numerous BIOS workarounds in it.
El Torito, the standard enabling bootable CDs, also had problems when it first came out.
Another example:
https://askubuntu.com/questions/521293/an-ubuntu-command-bri...
I had a Haswell-era MiniITX Gigabyte motherboard that had a similar issue. Installing the Clover/Chameleon and booting into macOS messed up the EFI and the system wouldn't boot. Went through two motherboards before I bought a different brand.