Ubuntu 17.10 pulled: Linux OS knackers laptop BIOSes, Intel kernel driver fingered Canonical has halted downloads of Ubuntu Linux 17.10, aka Artful Aardvark, from its website after punters complained installing the open-source OS on laptops knackered the machines. Specifically, the desktop flavor of Artful Aardvark, released in October, has been temporarily pulled – the server builds and other editions …
These machines are not really permanently borked. It is possible to reflash them, which restores normal BIOS functionality. The difficulty is that Lenovo only supplies reflashing tools which work under Windows, and in order for these to work you need to boot Windows. Which is tricky, if your only OS available on disk is Linux, and you cannot boot anything else from USB.
Some affected users managed to attach CDROM via USB and proceed from there. Ideally Lenovo should provide BIOS reflashing tool which works under Linux :-(
I've used an Intel BIOS tool, some time in the past, that booted and updated the BIOS from a USB flash drive. So it was OS-independent.
THAT is the kind of BIOS tool that is needed - not something that REQUIRES WINDOWS to run. Have it boot it's OWN operating system or not even bother with an OS. Even DOS would work for this kind of thing.
"'ve used an Intel BIOS tool, some time in the past, that booted and updated the BIOS from a USB flash drive. So it was OS-independent.
THAT is the kind of BIOS tool that is needed - not something that REQUIRES WINDOWS to run. "
From what I have read on that Lenovo forum, they do offer this... but without the ability to boot from a USB device and with no internal optical drive, it doesn't do much good.
but without the ability to boot from a USB device and with no internal optical drive, it doesn't do much good.
BIOS updates like this do not boot from a USB device, they read the BIOS image to be flashed from a USB device, so being unable to boot from USB does not indicate that it will be unable to read an image file from a USB device.
"BIOS updates like this do not boot from a USB device, they read the BIOS image to be flashed from a USB device, so being unable to boot from USB does not indicate that it will be unable to read an image file from a USB device."
I don't actually have such a laptop in front of me now, but the impression I got from what I read is that the .iso image from Lenovo boots into some type of runtime environment and executes a flash utility, and that obviously will depend on the ability to boot from a flash drive.
What you describe sounds like an emergency recovery mode. If the BIOS image in NVRAM is defective and cannot be executed or if you hold a certain key when turning the PC on, it may look for a file of a certain name in the root directory of the first USB device found (you'd generally only have one installed then), but that may or may not be possible with the UEFI borked as it is.
From what I understand, the reason the device can't boot from USB is that the system can't update its device table; whatever was installed at the time the bad Ubuntu update ran is forever what it thinks is installed-- so if no USB devices were plugged in at that time, it will always think none are plugged in now. That will probably also affect the emergency recovery, it seems, if it doesn't think that the USB device exists.
None of the posts on the Lenovo forums about this glitch described the possibility of using a recovery mode as such. Several people went so far as to remove and replace the UEFI chip from the motherboard, which seems a little bit premature to me.
This post has been deleted by its author
"Better still, one that doesn't require booting from anything that involves USB (because it's borked on affected machines - read the article!) - or CD or DVD (because that's no longer available on most new laptops.)"
If the afffected laptops support it, booting over the network is a possible way out.
Back in the day, floppies would have provided an alternative. Please let's not go back there.
Network booting is all well and good, but the newer systems also do away with network adapters. You only need wireless. And as someone who has got going too many systems via network boot, I have never got one going over wireless yet. EFI (everythings fu&^ed iinit?).
Wifi PXE? Hmm that would mean battling, shoddy PXE stack (surprisingly common), WPA issues or setting up an open network, cross your fingers and prey that the wifi drivers are adequate.
Back in the day, floppies would have provided an alternative. Please let's not go back there.
Why? There's really nothing wrong with trying to install Slackware from floppies, only to find that disc 15 of 18 is no longer readable and crashes the whole install..
(Just as well my friend had internet access at work and could re-download the floppy images.)
"Better still, one that can self-boot and doesn't need any installed OS."
I have a clutch of Lenovo Desktops and Laptops. For all of them, BIOS flashing tools are available as Windows software and as self-boot.Of course that's not much use if a rogue OS has prevented USB boot ...
If you did not know, built into all modern Intel-based platforms is a small, low-power computer subsystem called the Intel Management Engine (ME). It performs various tasks while the system is in sleep mode, during the boot process, and also when your system is running.
Architecturally, the ME varies from model to model, and over the past decade it has been growing in complexity. In general, it consists of of one or more processor cores, memory, system clock, internal bus, and reserved protected memory used as part of its own cryptography engine. It has its own operating system and suite of programs, and it has access to the main system's memory, as well as access to the network through the Intel Gigabit Ethernet Controller. If you had control over the ME, then it would be a powerful subsystem that could be used for security and administration of your device.
The ME firmware runs various proprietary programs created by Intel for the platform, including its infamous Active Management Technology (AMT), Intel's Boot Guard, and an audio and video Digital Restrictions Management system specifically for ultra-high definition media called "Intel Insider." While some of this technology is marketed to provide you with convenience and protection, what it requires from you, the user, is to give up control over your computer. This control benefits Intel, their business partners, and large media companies. Intel is effectively leasing-out to the third-parties the rights to control how, if, and when you can access certain data and software on your machine.
Leah Rowe of GNU Libreboot states that the "Intel Management Engine with its proprietary firmware has complete access to and control over the PC: it can power on or shut down the PC, read all open files, examine all running applications, track all keys pressed and mouse movements, and even capture or display images on the screen. And it has a network interface that is demonstrably insecure, which can allow an attacker on the network to inject rootkits that completely compromise the PC and can report to the attacker all activities performed on the PC. It is a threat to freedom, security, and privacy that can't be ignored."
At this time, developing free replacement firmware for the ME is basically impossible. The only entity capable of replacing the ME firmware is Intel and its OEM partners. And, since the ME is a control hub for your machine, you can no longer simply disable the ME like you could on earlier models, such as the Libreboot X200 laptop.
This means that if in the future we want more hardware that can achieve Respects Your Freedom certification, we will need to make it a "High-Priority" to support the work of those who are getting GNU Libreboot and 100% free system distributions running on other architectures, such as ARM, MIPS, and POWER8.
"Ideally Lenovo should provide BIOS reflashing tool which works under Linux :-("
Any why ?
A post further down states Ubuntu isn't supported by Lenovo, why should they expend resources? They support Windows and supply a BIOS flash tool for Windows - Sorted.
Physician Heal Thyself
you caught it, you fix it.
This post has been deleted by its author
This post has been deleted by its author
If it turns out X number of laptops ARE permanently borked, what happens then? Can anyone be sued, or is it teeth gnashing time?
Just like MS and every other software purveyor, the software is released "as-is" [...] [without] fitness for any particular purpose.
If your BIOS is already affected by this blunder, you may have to replace the firmware's flash memory chip – or the whole motherboard – if reseting the BIOS or this suggested workaround, or some other remedy, do not resolve the matter.
That is when you appreciate the Gigabyte dual Bios boards ... unless you switch bios and reboot into Artfully Awkward again, of course ... ;-)
> At least Windows never killed my BIOS...
Not your machine perhaps, but there have been plenty of reports of Windows also doing it in recent years.
That said, I don't think this is a really either Windows or Linux issue. I think the blame rests squarely with bloated UEFI design and in particular lazy implementations by many hardware manufacturers. It's plain that the design can't be very robust if software bugs can so easily upset the boot firmware.
"Not your machine perhaps, but there have been plenty of reports of Windows also doing it in recent years.
That said, I don't think this is a really either Windows or Linux issue. I think the blame rests squarely with bloated UEFI design and in particular lazy implementations by many hardware manufacturers. It's plain that the design can't be very robust if software bugs can so easily upset the boot firmware"
^ I agree with this and anything that is so fragile and so easily corrupted (irrespective of OS) is not fit for purpose. It's about time that the Unified EFI Forum started work on a competent, and above all robust, replacement for UEFI.
I never recall good ol' BIOS have this many and this severe issues.
Totally agree. Poor design. UEFI is a dreadful pile of dingo's kidneys. There's no way an OS should be farting about with BIOS code/settings and able to fubar your machine. Modern OSs are big and generally full of bugs and have no business messing about in the BIOS. I'm surprised this sort of fuckup doesn't happen more often. All mobos should have dual BIOSs to get you out of these situations and BIOS flashing/setting should only be possible from with the BIOS itself.
"That said, I don't think this is a really either Windows or Linux issue. I think the blame rests squarely with bloated UEFI design"
This isn't actually about UEFI at all. It's a level lower than that. This is a mechanism Intel designed to allow modification of the firmware from the OS *regardless what that firmware is* - it could be a UEFI firmware or some entirely different type of firmware. This SPI mechanism isn't part of the UEFI spec, nor (AIUI) can the implementer of the firmware *itself* really affect anything the SPI mechanism can do.
There's an explanation of SPI in the documentation for it in the kernel: https://github.com/torvalds/linux/blob/master/Documentation/mtd/intel-spi.txt
The funniest thing of all is this.
IBM "open sourced" the PC specs ( not the BIOS granted, that was Compaq ) and anyone can spec out a PC motherboard layout if they have the skills. Windows people banging about FOSS and open-source is shite are running their favourite, beloved O/S on open-source hardware!
> "What, just because Intel designed, wrote, and released the driver that's causing the problem? Never!"
There's a blackbox warning on the code. The fault ultimately lies with Canonical for taking something with that sort of warning and enabling it in their default configuration.
I'm sure if Windows had ever killed your BIOS, you would have been rushing to blame Intel or Lenovo .....
This has shades of an issue from several years ago, with some read-only optical drives taking liberties with the standards. They used the "write" instruction to initiate a firmware upgrade. Some Linux distributions used a hardware detection tool that attempted to determine whether an optical drive was read-only or write-capable by attempting a write operation. Nothing would actually be written to the disc, since the first block of data would contain a deliberate error. A writable drive should respond "OK, begin sending data", accept the data and then bomb out with a checksum error. A read-only drive should respond to the "write" instruction with "command not recognised" ..... Unless it was falsely interpreting the "write" instruction to mean "new firmware coming up" and responding "OK, begin sending data" ..... then overwriting the beginning of its own firmware with the test data .....
It could happen with any Operating System -- even Mac OS, since even Apple can't always control all their upstream suppliers. All it takes is for two people to interpret the wording of a standard differently, or one to ignore it completely .....
Somebody should have to take responsibility for this; but everybody has a good case for pointing the finger at somebody else, and it's the users who end up suffering.
That should be "Lest", as in Lester Haines.
Yup, shockingly it turns out that all software has bugs, and Linux is no exception. Windows is certainly no exception either, nor is MacOS.
Next!
"To be fair, Windows doesn't have bugs, Windows IS a bug."
"To be fair" - on these openly belligerent penguinista infested forums
that'll be a first
Be nice to see a post about an OS that isn't Linux not defaced by them (I appreciate this was about Linux but as ye sow so shall ye reap). Don't like something guys - here's a though - don't tell the rest of us because we don't care.
One of the nastiest Windoze virus infections - prevalent a few years ago - was called CIH. It would actually fry the BIOS on some machines, and render most machine unbootable by screwing up the BIOS settings. It wasn't (usually) detected by the usual "anti-virus" snake-oil, so it would infect plenty of other machines (mostly by sending spam emails) before triggering its BIOS-wrecking payload.
Remember - it's only M$-based machines that suffer mass virus infections!
> Why is this [a kernel driver for the SPI flash] even a thing?
Imagine that you wanted to write a Linux utility to reflash the BIOS. This would require some way for a user-mode program to access the BIOS flash. A kernel driver to do that is the obvious method.
See posts anove for why a Linux utility to reflash the BIOS is desirable...
> Why is this [a kernel driver for the SPI flash] even a thing?
Actually, I meant "why is SPI flash a thing."
At a minimum, SPI should be an option that is disabled by default. But preferably (IMHO) it shouldn't even exist. The BIOS' flash storage should be read-only outside of the BIOS' own configuration screens.
Otherwise some random software cock-up could brick your shiny new laptop (Q.E.D.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
