Hacker News Reader

Comment by self_awareness | Hacker News Reader

The amount of bugs in UEFI of new motherboards shocks me. Bugs are all over the place; sometimes I change an option in Setup only to find out it's disabled after reboot, and switching the option ON for the 2nd time works. Or, on my motherboard boot menu is bugged. To boot my Windows disk, I have to choose 'Switch to English' menu entry. I'm afraid to clear EFI vars because currently at least it works, who knows what'll happen when I clear EFI vars.

This really discourages me from buying new hardware.

View on HN

I feel your pain but it really doesn't shock me at all. Closed source blackbox firmware made mainly by hardware vendors? What could possibly go wrong. Even AMD and Intel are very hit-or-miss with the quality of the software they produce, can you imagine the random mobo maker? Have a look at some of the vendor-maintained forks of u-boot and Linux (whose code they have to publish because the GPL) and see how many bugs you can find.

Meanwhile the software embedded in these boards becomes more and more complex with basically a full blown embedded OS, graphical interface etc...

Software shops have a hard enough time writing robust software these days, ASRock probably has a team of a dozen or so glorified interns copy-pasting from stack overflow (or worse, contracting third parties do to it). I'm exaggerating a bit of course but not by a massive amount from my personal experience working with hardware shops.

Almost certainly the code doing the GPT partition table recovery here is stock edk2 + a bunch of proprietary drivers to initialize clocks on the motherboard. The edk2 code is open source under a BSD-ish license, although I take your point that the full blob running on the ASRock motherboard doesn't come with compilable source so it's not much help. https://github.com/tianocore/edk2

After this incident, I am seriously considering buying a device with all-open-source firmware (like the Raptor Talos/Blackbird on HN recently) for work, just so that I don't have to guess what the mainboard is doing, but can actually look.

And perhaps even other people having had a look what the firmware actually does, or fix the behaviour myself (like adding a "Do you really want to?" popup before it wipes the superblocks).

UEFI implementations are a bugfest, with every other board exhibiting a new idiosyncrasy. I probably don't even remember half of the bugs I've encountered.

My favorite one was when the integrated EFI shell wouldn't scroll, so every new line would just print over the previous one.

The most obnoxious and common is hardcoding the boot path to be "\EFI\BOOT\BOOTX64.efi", ignoring what the boot entry says on that matter.

> The most obnoxious and common is hardcoding the boot path to be "\EFI\BOOT\BOOTX64.efi", ignoring what the boot entry says on that matter.

Tell us what manufacturer does that, so I can avoid ever buying from them.

Most recent bug: UEFI ignores POST timeout and basically skips it when a specific SATA drive is connected.

I've ever seen \EFI\BOOT\BOOTX64.efi used as a last resort used if the system's entries don't point to a valid loader. Pretty grim if that was all your system would allow you to use.

> of new motherboards

This mainboard was released in Q2 2014. It still has DDR3. Its manufacturer warranty expired last year!

This is hardly representative of new hardware.

Are you sure they are talking about the motherboard in the article, or other boards they use?

new enough in the sense of UEFI and BIOS which is spoken about. UEFI is from 2007, so they had 7 years to learn how to write code for it and for their own hardware. if it was a 2008 board it would be so new you could expect this kind of random bugs. 7 years on... it's becoming a sign of something which is inherently broken / never going to work as we hope.

i don't like this either. especially because often bugs are in places which aren't even necessary to begin with. Like if you find invalid data as a firmware on some device you need to use, just give a message about it, BUT LEAVE IT ALONE DON'T DESTROY IT! people think it'll be a clever trick to do these things, but really it will be asking for trouble if you scale it up to loads and loads of users who YOU CAN'T EXPECT TO FOLLOW DEFAULT / RECOMMENDED PROCEDURES.

I mean really, all that was needed was to read the content of the disk, and if you couldn't use it. just print that it was unusable. but somehow someone put in write functions to destroy peoples data because they assumed they knew all cases that would come by. instead of assuming they don't know everything and building a more careful product. the unknown unknown is what hit this developer and user of the product. it's a shame this happens especially with such a framework who is supposed to replace 'legacy' things. if this is a sign of how modern frameworks work for these kind of interactions , i'll take my legacy rubbish over it any day of the week.

This is very discouraging to hear, especially since I'm currently choosing a motherboard for a new PC build. Is there any good way to determine the quality of motherboard firmware? Are there any recommended vendors?

ASUS are generally good for consumer level boards. I've heard of the occasional bad board, but (from my perspective) they seem to be rare.

ASRock, as you see from this HN posting, has a reputation for not being quite as polished. Probably best to skip for now if you don't want to be messing with potential weirdness.

If you're looking for higher end things, Supermicro boards are good. Recent weirdness - "Chinese installed backdoors on Supermicro boards" - aside that is. ;)

Urgh - I find this sometimes too since upgrading that randomly bluetooth would become disabled on boot :/

Reply on news.ycombinator.com