Ubuntu 17.10 Temporarily Pulled Due To A BIOS Corrupting Problem

[Cape]

Don't worry guys, just ask the NSA to remotely fix the BIOS via IME ;-)

Intel is truly a furked up platform. Im never going to buy x86 any longer. Tons of ARM and upcoming RISC-V that offers close-to perfs at a fraction of Watts.

[grzadr]

Maybe a silly question, but I have installed Kubuntu 17.10 on my new laptop few weeks ago. How can I check if everything is all right with my bios?

[grzadr]

Maybe a silly question, but how to check if installation of Ubuntu 17.10 did not corrupt my BIOS? Everything seems to work fine. Should I change some options and check if they persist after reboot?

[FirstPersonBSOD]

Ubuntu installer still asks you to type mount points with special characters before even asking for the keyboard layout. Because they assume everyone's using US keyboard. It's telling a lot about QA.

I reported this bug back when Artful was in beta, never heard a single word from the development team: https://bugs.launchpad.net/ubuntu/+s...y/+bug/1707857

[cen1]

This is exactly why I wait for a few months before upgrading any distro.

[pracedru]

Wow. That is next level crap right there
People having their hardware bricked by Ubuntu can't be good for the reputation of Linux.
I sure hope they get this fixed quickly, and perhaps also find a fix for people which hardware is affected by this.

[Anty]

But for what freaking reason linux wants to modify some BIOS settings? I understand reading something (but still fishy as there are too many BIOS variants) but writing? Or is it just driver which writes something even it was not asked to do it? I hope it is not generic problem and having desktop ryzen there won't be a day when everything is FUBAR because of this.

[cen1]

After reading the mailing list.. whoa, I am glad I am not one of the affected people. It esentially bricks your laptop with no solution so far. I would be super pissed.

[coder]

Is there any chance this is an Apollo Lake bug? I know some of Lenovo's entry-level laptops use it, and was going to install 17.10 on an Apollo Lake desktop board.

[c117152]

could it be the way that UEFI variables are being accessed? that the vendor has taken some short cuts and used the same chip for both UEFI firmware or BIOS, and the non-volatile UEFI settings?

Not sure it's related, but many of the volatile memory regions that are used between sleep power state are usually implemented non-volatile to prevent a state loss if power was lost during windows hibernation. I suppose a switch statement defaulting on such a state could fail a later bounds check for some variable and end up putting the system in a state where it doesn't read the USB boot media or lets people access the bios menu. But it would still be a linux bug corrupting the memory region in the first place...