Intel SPI Driver in Ubuntu 17.10 Release Might Corrupt Your Laptop Bios

[James21]

I have had several Dell branded laptops unexpectedly become totally unresponsive (apart from the power button lighting up) while installing the Windows 10 Creators or Windows 10 Creators Fall updates.
A couple were able to be salvaged by leaving the system battery unplugged and the CMOS battery unplugged for an extended period of time (a bit hard when the batteries are deep inside the units), others never recovered at all.

So it's not just a Linux thing, it happens with Windows 10 as well.

 

[B00nie]

Just like Puma 6 is an Intel problem, not an ARRIS or Netgear problem. Trust me, the end users who are affected don't see it this way.

And yes, this is a Linux problem, or at least an Ubuntu problem, because the driver is integrated into the kernel, so if you want that version of Linux, you will get the corrupted driver.


Note that it is not a kernel module (as it should be, or as a separate install as it would be in Windows), but it is in the very core of what makes Linux Linux - the kernel.

That would be fine except you can choose which kernel you use.

 

[jardows]

That would be fine except you can choose which kernel you use.

That's fine and dandy, but misses my point. How did this happen in the first place, and how can it be prevented from happening again? If this is something that comes with the 4.13 driver, then the kernel.org team needs to review how they implement driver integration with the kernel. If it is simply an Ubuntu issue, where they bundled it with the Linux kerenel in this distribution, how can they make sure they don't release a customized kernel in a full release that ruins hardware! Where is the breakdown? Simply trying to state "All's well in Linux Land because this is an Intel only problem" is naive, and Desktop Linux cannot afford to have this kind of bad publicity.

Since Linux is a community OS, surely the community should be concerned about these issues.

 

[PaulP]

Shame on manufacturers that make systems where the BIOS can't be reset/reloaded in the case it becomes corrupted. Having to replace a motherboard/system just because the BIOS became corrupted just sucks.

 

[B00nie]

Shame on manufacturers that make systems where the BIOS can't be reset/reloaded in the case it becomes corrupted. Having to replace a motherboard/system just because the BIOS became corrupted just sucks.

It's probably a part of the 'secure boot' etc. nonsense. If bios replacement would be easy, it would be trivial to load open source and alternative bioses. Manufacturers, Microsoft and powers behind them (RIAA/MPAA etc) do not want freedom for consumers to use their devices.

 

[thesmokingman]

Intel is almost as bad as Apple these days, lol.

 

[B00nie]

Is the blame entirely in the right place? It just seems odd that in 2017 you could let the operating system straight up break the bios. Aside from ensuring the BIOS/UEFI specifications are implemented correctly and prevent bricking scenarios, maybe we need to bring back the "backup bios" that was a thing after the CIH/Chernobyl virus.

Intel should put on its Superman cape and find a way to use the Management Engine to fix this.. that'd get them some good will points.

A faulty driver in Windows would just as well destroy the bios. In fact in Windows bios corruption and malware injection has been commonplace through attacks. They're just so common problems that they don't even break the news threshold.

 

[BulletDust]

That's fine and dandy, but misses my point. How did this happen in the first place, and how can it be prevented from happening again? If this is something that comes with the 4.13 driver, then the kernel.org team needs to review how they implement driver integration with the kernel. If it is simply an Ubuntu issue, where they bundled it with the Linux kerenel in this distribution, how can they make sure they don't release a customized kernel in a full release that ruins hardware! Where is the breakdown? Simply trying to state "All's well in Linux Land because this is an Intel only problem" is naive, and Desktop Linux cannot afford to have this kind of bad publicity.

Since Linux is a community OS, surely the community should be concerned about these issues.

Once again, bear in mind that the release in question is a bleeding edge non LTS release, you use these releases at your own risk and Microsoft use the same release/testing model on their own OS which is in no way suited to such rolling releases - Linux has been using the model for many years with very little issues, the Microsoft updating process is plagued with problems.

Hence the reason why I stick to 16.04 LTS for my main PC.

It's a UEFI issue based on an Intel driver and as far as I can tell it's not even bricking devices.

 

[jardows]

Once again, bear in mind that the release in question is a bleeding edge non LTS release, you use these releases at your own risk and Microsoft use the same release/testing model on their own OS which is in no way suited to such rolling releases - Linux has been using the model for many years with very little issues, the Microsoft updating process is plagued with problems.

Hence the reason why I stick to 16.04 LTS for my main PC.

It's a UEFI issue based on an Intel driver and as far as I can tell it's not even bricking devices.

I am surprised about how flippant you are about this. It certainly isn't the end of the world, but it certainly is bad news the Linux community would want to avoid.

Imagine this - if the latest Windows 10 update contained a driver that caused some hardware to malfunction, you and many others would be screaming about the poor QA, and how horrible Microsoft and Windows are. There would be plenty of people who would say "That's why I'm still on Windows 7, Windows 10 is just a piece of trash." The reality is, for Ubuntu, this is the exact same issue, yet it seems like the community (at least here on [H]) sees it as no big deal.

 

[BulletDust]

I am surprised about how flippant you are about this. It certainly isn't the end of the world, but it certainly is bad news the Linux community would want to avoid.

Imagine this - if the latest Windows 10 update contained a driver that caused some hardware to malfunction, you and many others would be screaming about the poor QA, and how horrible Microsoft and Windows are. There would be plenty of people who would say "That's why I'm still on Windows 7, Windows 10 is just a piece of trash." The reality is, for Ubuntu, this is the exact same issue, yet it seems like the community (at least here on [H]) sees it as no big deal.

It's non LTS and use at your own risk - That's the idea of any release that's not LTS, it's used for testing, for finding issues just like this one. That's as factual as stating that Windows 10 is garbage as Microsoft are trying to use the same model and it doesn't work with the NT kernel.

What you're trying to do is take a dump on Linux, but you're dumping on the very release that's supposed to have issues.

 

[jardows]

That's the idea of any release that's not LTS, it's used for testing, for finding issues just like this one.

Uh, no, that's what betas or development builds are for. Do you even know what LTS stands for? It stands for Long Term Support. It has nothing to do with a stable vs beta/development snapshot. A company can have several versions of "LTS" software. 17.10 may not be LTS, but it is the latest release version, not a beta or development version.
Maybe you'll understand FreeBSD nomenclature better than Windows equivalents - In the FreeBSD world, you are using the equivalent of 10.4-RELEASE, when the latest release is 11.1-RELEASE. What you are describing 17.10 to be would be the equivalent of FreeBSD 12-CURRENT.

I could certainly expect a large number of bugs and crashes in a development or beta release. I would be upset if it ruined my hardware, but it is use at your own risk. There is no such disclaimer on Ubuntu 17.10 - it is supposed to be stable, tested, no longer beta or development.

What you're trying to do is take a dump on Linux, but you're dumping on the very release that's supposed to have issues.

What you are trying to do is polish a turd. Canonical laid one. It happens. It's ok to admit that even the Linux developers can make a mistake. Refusal to admit it, or that it is a problem, is just as bad as the iPeople.

 

[BulletDust]

Uh, no, that's what betas or development builds are for. Do you even know what LTS stands for? It stands for Long Term Support. It has nothing to do with a stable vs beta/development snapshot. A company can have several versions of "LTS" software. 17.10 may not be LTS, but it is the latest release version, not a beta or development version.
Maybe you'll understand FreeBSD nomenclature better than Windows equivalents - In the FreeBSD world, you are using the equivalent of 10.4-RELEASE, when the latest release is 11.1-RELEASE. What you are describing 17.10 to be would be the equivalent of FreeBSD 12-CURRENT.

I could certainly expect a large number of bugs and crashes in a development or beta release. I would be upset if it ruined my hardware, but it is use at your own risk. There is no such disclaimer on Ubuntu 17.10 - it is supposed to be stable, tested, no longer beta or development.

WTF are you on about?

Non LTS is effectively beta and chucking a little snippet of FreeBSD in there doesn't make you sound more knowledgeable that you really are - Because it's obvious you have no idea.

From what I'm reading, no hardware is ruined and if you're at all worried about issues stick 100% with either CB under [cough] Windows 10 or LTS under xbuntu variants - Every other release is effectively beta and it's purpose is to test for issues exactly like the one being discussed.

It's pointless getting pissed when you're playing chicken on the highway on any system that's even remotely important.

 

[auntjemima]

Uh, no, that's what betas or development builds are for. Do you even know what LTS stands for? It stands for Long Term Support. It has nothing to do with a stable vs beta/development snapshot. A company can have several versions of "LTS" software. 17.10 may not be LTS, but it is the latest release version, not a beta or development version.
Maybe you'll understand FreeBSD nomenclature better than Windows equivalents - In the FreeBSD world, you are using the equivalent of 10.4-RELEASE, when the latest release is 11.1-RELEASE. What you are describing 17.10 to be would be the equivalent of FreeBSD 12-CURRENT.

I could certainly expect a large number of bugs and crashes in a development or beta release. I would be upset if it ruined my hardware, but it is use at your own risk. There is no such disclaimer on Ubuntu 17.10 - it is supposed to be stable, tested, no longer beta or development.


What you are trying to do is polish a turd. Canonical laid one. It happens. It's ok to admit that even the Linux developers can make a mistake. Refusal to admit it, or that it is a problem, is just as bad as the iPeople.

He's not worth it, man. This is what he does every time.

If windows released this in an update and BIOSes were corrupted they would be screaming for Microsoft's head, not Intel's. But it's Linux it happened in, so it's cool, it's Intel's problem.

 

[BulletDust]

He's not worth it, man. This is what he does every time.

If windows released this in an update and BIOSes were corrupted they would be screaming for Microsoft's head, not Intel's. But it's Linux it happened in, so it's cool, it's Intel's problem.

It's not rocket science! It's a non LTS release! It's purpose, just like non CB releases under Windows 10 (Windows Insider Builds), is to find such issues!

Dear gawd!

 

[BulletDust]

He's not worth it, man. This is what he does every time.

If windows released this in an update and BIOSes were corrupted they would be screaming for Microsoft's head, not Intel's. But it's Linux it happened in, so it's cool, it's Intel's problem.

Under the CB of Windows 10, yes - I'd be there pissing all over Microsoft! However if it was the Windows Insider build with issues my opinion would be no different than it is here.

 

[Zibri]

1. Install Ukuu

2. Update the kernel
Select the kernel 4.14.9 and select Install.

3. Restart the system with the latest kernel
From GRUB select the option which starts with "Advanced options".
Select Ubuntu GNU/Linux, with Linux 4.14.9-generic

4. Restart again and go into the BIOS

At this point you will be able to boot into another USB disk

 

[yourgrandma]

I have had several Dell branded laptops unexpectedly become totally unresponsive (apart from the power button lighting up) while installing the Windows 10 Creators or Windows 10 Creators Fall updates.
A couple were able to be salvaged by leaving the system battery unplugged and the CMOS battery unplugged for an extended period of time (a bit hard when the batteries are deep inside the units), others never recovered at all.

So it's not just a Linux thing, it happens with Windows 10 as well.

Have seen this happen on quite a few Dell AIOs after the upgrade to windows 10 fiasco, completely unrecoverable without swapping the bios chip.