Please create an account to participate in the Slashdot moderation system


Forgot your password?
Bug Operating Systems Ubuntu Linux IT

Ubuntu 17.10 Temporarily Pulled Due To A BIOS Corrupting Problem ( 167

An anonymous reader writes: Canonical has temporarily pulled the download links for Ubuntu 17.10 "Artful Aardvark" from the Ubuntu website due to ongoing reports of some laptops finding their BIOS corrupted after installing this latest Ubuntu release. The issue is appearing most frequently with Lenovo laptops but there are also reports of issues with other laptop vendors as well. This issue appears to stem from the Intel SPI driver in the 17.10's Linux 4.13 kernel corrupting the BIOS for a select number of laptop motherboards. Canonical is aware of this issue and is planning to disable the Intel SPI drivers in their kernel builds. Canonical's hardware enablement team has already verified this works around the problem, but doesn't provide any benefit if your BIOS is already corrupted.
This discussion has been archived. No new comments can be posted.

Ubuntu 17.10 Temporarily Pulled Due To A BIOS Corrupting Problem

Comments Filter:
  • That ain't right! (Score:4, Insightful)

    by Anonymous Coward on Wednesday December 20, 2017 @02:08PM (#55777349)

    How the hell have we let what's supposed to be ROM get so fucked up by a simple software upgrade? That, Ain't, Right!

    • It's been EEPROM for decades. And if you expose an interface for updates, that interface is an exposed risk. Especially in the driver for the SPI bus that actually does the writing.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        You don't need to overwrite the EEPROM to cause problems. In this case, since it's caused by the SPI driver, it looks like corrupt data is being written to the volatile memory used by the BIOS to save settings. This is battery backed memory that can be reset, but it's a bit trickier in laptops.

        • In this case, at least one person involved was unable to resolve it by replacing the CMOS battery:

          • I wonder if they did a half-hour+ "thorough reset", or just a quick power removal. I.e. did they just get unlucky that a "soft" reset left some bad data behind in volatile memory, or if the EEPROM itself was modified.

            I miss the old days when you had to physically move a motherboard jumper if you wanted to modify the EEPROM. Almost as much as I miss the existence of hardware-enforced write protection toggles on removable media. (My first USB drive had one - I don't think I've even seen one since, though I'

            • I miss the old days when you had to physically move a motherboard jumper if you wanted to modify the EEPROM.

              There are still PC motherboards with a write enable jumper, but they are pretty much all server boards. Remember server cases with keylock switches? They're still out there...

            • A half-hour? Just drain the caps with a few presses of the power button.

              • That almost always works. Unfortunately, charges can linger in the chips themselves as well. Rare, but can cause no end of headaches when the wrong bit(s) remain set and you don't realize that's possible.

            • I miss the old days when you had to physically move a motherboard jumper if you wanted to modify the EEPROM.

              Just as I miss the days of setting master/slave on IDE drives or bus positions on SCSI disks, or IRQ numbers of IO/SB cards.

              Those days.

              • Really? Was there an advantage to those that I'm missing compared to modern solutions?

                Writing to EEPROM is typically a very rare activity - to the point that any particular write has a good chance of having been unintentional/unauthorized by the owner. Seriously - how many people do you know who actually, for example, update their motherboard's BIOS? And of those who do - how many do so for reasons that haven't already cost them enough problem-solving effort that the added effort of changing a jumper is tr

                • by sabri ( 584428 )

                  Really? Was there an advantage to those that I'm missing compared to modern solutions?

                  Job security.

                • Did you mean to reply to my comment with this? I didn't mention anything about BIOS. Just that I missed the hardware that needed IRC and bus position jumpers, the same way that I miss Turbo C and Turbo Pascal. Those were good days.

                  • Yeah, I thought you were being a smartass, comparing the headaches around the hardware you mentioned to the nuisance of an EEPROM protection jumper.

                    My apologies. Those where good days.

    • Because FOSS is so much better and without any flaws! Not like the closed source commercial counterparts. - Sarcasm aside, no matter what model, if QA is seen by developer dominated software providers as an afterthought then things like this happen. It is in the same category where an equation editor in a word processor apparently has so much might that it can hose the entire system. I fully agree - "That, Ain't, Right!"
  • Anybody know if the issue is a bug in the driver code or is the driver inadvertently exposing a faulty bios implementations
    • by omnichad ( 1198475 ) on Wednesday December 20, 2017 @02:17PM (#55777463) Homepage

      From the Canonical bug report []:
      At least on Lenovo Thinkpad Yoga, the BIOS seems to monitor the SPI-NOR
      write protection bit and if it is flipped to read/write it assumes the
      BIOS configuration was changed on next reboot. It then, for unknown
      reasons, resets the BIOS settings back to default.

      • by Hal_Porter ( 817932 ) on Wednesday December 20, 2017 @02:39PM (#55777683)

        Lenovo need to stop people writing the Bios because otherwise they'd able to remove the crapware Lenovo put in the Bios to stop people removing the crapware they put in the Windows by installing a fresh Windows image.

        With an unmodified Lenovo Bios the crapware will be re-installed via Windows Platform Binary Table []

        Beginning with Windows 8, a PC manufacturer can embed a program - a Windows .exe file, essentially - in the PC's UEFI firmware. This is stored in the "Windows Platform Binary Table" (WPBT) section of the UEFI firmware. Whenever Windows boots, it looks at the UEFI firmware for this program, copies it from the firmware to the operating system drive, and runs it. Windows itself provides no way to stop this from happening. If the manufacturer's UEFI firmware offers it up, Windows will run it without question.

        Were it not for this Bios resetting feature - a ludicrously determined user could do the following

        1) Remove Windows
        2) Use some other OS to dump the Bios out
        3) Hack said dump to mess up the Windows Platform Binary Table and reflash it
        4) Reinstall Windows from an image

        And then they'd have a copy of Windows with no Lenovo Service Engine installed! The horror! Instead it seems like Lenovo have had the Bios reset itself to stop step 3), so the determined user would still have LSE installed.

        • by Dorianny ( 1847922 ) on Wednesday December 20, 2017 @03:06PM (#55777925) Journal
          Fanciful theory however Occam's razor principle strongly suggests this being a simple bug in the Bios implementation rather then malicious intent. Lenovo is on the hook for the motherboard replacement required to fix the locked Bios for any device that is still under warranty. Seems like an incredibly stupid thing to do just to stop people from being able to remove the Lenovo Server Engine
      • by Junta ( 36770 )

        Probably some UEFI configuration utility that sets write and then some sort of staged config change update area.

        Presumably if the system does not have a new bios, it then goes to process what turns out to be an empty changeset, which was not a case they anticipated, and hitting some weird fallback to recover from invalid utility behavior.

  • by oobayly ( 1056050 ) on Wednesday December 20, 2017 @02:16PM (#55777461)

    I have a Lenovo Yoga which I dual boot with Linux Mint Sarah and just after I installed 1709 Fall Creators Update the fingerprint reader stopped working. I gave up trying to remedy it and reset Windows, but that didn't fix it.

    I then realised that it wasn't shutting down properly either. ACPI shutdown in both OSs would leave it halted but powered on, so the only way to restart was to hold the power button to kill it, and then switch on.

    I finally checked the warranty and saw it was 14 months old so took it apart, removed the battery and motherboard battery, left it for an hour, powered it on, flattened the partition table an reinstalled. Works perfectly again, but after a huge amount of time wasted.

    So, it's either a coincidence, or there's something modern OSs are trying to do which screw up BIOSs.

    • It's probably the way the fingerprint reader integrated with Windows logon. The upgrade from 7 to 10 outright broke several laptops in a way that required a format/reinstall due to completely corrupting the login system to the point where neither using a password nor a password reset solved anything.

    • Oh yes, and along with it not powering down, it would also take about 35 seconds from lights on to STARTING the POST check. Multiple bios reload defaults also had no effect. Just the "Kill the power" option.

    • by drinkypoo ( 153816 ) <> on Wednesday December 20, 2017 @03:52PM (#55778343) Homepage Journal

      I finally checked the warranty and saw it was 14 months old so took it apart, removed the battery and motherboard battery, left it for an hour, powered it on, flattened the partition table an reinstalled. Works perfectly again, but after a huge amount of time wasted.

      If removing the batteries solved the problem, then your problem wasn't BIOS. It was CMOS. The "CMOS RAM" is the volatile memory which stores settings used by the BIOS. The BIOS itself is stored in non-volatile memory. This was originally a PROM in the IBM PC, but today is pretty much always Flash ROM. Sometimes it's a flat quad package, sometimes it's a serial 8-pin DIP and it has to be shadowed into RAM just to function, but it's pretty much always flash. (Those ones are cool because they're usually socketed, and SPI-interfaced, which means they're useful for other projects...)

  • by Anonymous Coward

    Bad luck for this to happen during the year of the linux desktop.

  • Isn't wonderful (Score:5, Insightful)

    by DarkOx ( 621550 ) on Wednesday December 20, 2017 @02:40PM (#55777697) Journal

    That we have moved from simple reliable BIOS systems that provided a little boot code to get the system going on a ROM, to an advanced re-programable system so that software BUGs can now brick your PC!


    • by bws111 ( 1216812 )

      That happened over 20 years ago. Time to get over it.

      • by Anonymous Coward

        Or, time to fix it?

      • by Anonymous Coward

        It happened in 2011 actually. That was only 6 years ago. Your advice to "get over it" is unlikely to make the problems caused by it to go away. Making a bit of a fuss every now and then is actually less effort, and is at least more likely to improve the situation.

        • 2011? The first machine I owned that managed to brick itself in a failed BIOS update was a Gigabyte motherboard with a 200MHz Cyrix Pentium clone.
        • by bws111 ( 1216812 )

          Updateable BIOS's have been around since at least the mid 90s. BIOS has not been on a ROM since then.

    • by Junta ( 36770 )

      The difference is that formerly, the OS didn't dare include capabilities to screw with the BIOS ROM as a matter of course (it was always possible). There was too much concern that there wasn't enough consitency between vendors.

      Here you have Intel thinking the entire world is using Tiano core and Intel reference platform, so Intel feels more confident putting code mainline to screw with the SPI roms.

    • by AmiMoJo ( 196126 )

      It's the other way around. The BIOS was complex and did a huge amount of initialisation work that was then ignored by the OS anyway. It ran arbitrary code from option ROMs. And it was x86 only.

      UEFI isn't perfect, but at least it ditches most of that crap. My 2012 era laptop can boot to the login screen in under 4 seconds, faster than the old BIOS can POST.

    • That we have moved from simple reliable BIOS systems

      WTF? We never had that. The BIOS has for the past 30 years been a hacked together crapshoot for other systems to work around.

  • It was more than 10 years ago. There were some cdrom drives (LG I think) that interpreted some ATAPI command which was only used on cd recorders as a "upgrade firmware" command (or something like that). Some version of the kernel happened to send that command to every ATAPI device and so it corrupted said drives firmware.
    I was hit by the bug when booting a live cd on my brother's pc but it was recoverable and so I managed to write a correct firmware and got the drive working again.
    • Correction: It wasn't actually a kernel bug, it was a bug of the cdrom's firmware
      • by AvitarX ( 172628 )

        I'd argue that it was both.

        Sending junk commands isn't exactly something I'd think the kernel should do.

  • designing overcomplicated systems that are unmaintainable spaghetti code and get back to "keep it stupid simple" and things that just work, and not try to right the user, ...
  • I still have my bricked laptop from an attempted Ubuntu 9 to 10 migration. Luckily it was a really old laptop that I didn't really care to fix after that - just needed a floppy with the laptop's bios but couldn't find a working floppy drive or floppy to write on :/
  • Why has the world forgotten it?

  • I've had no problems so far, but will this brick my machine in the near future?
  • by Darkk ( 1296127 ) on Wednesday December 20, 2017 @04:17PM (#55778497)

    Good thing I have a motherboard with dual BIOS so if one gets screwed up due to a bad flash I can flip the switch to the back up BIOS and then copy itself over to the corrupted BIOS.

  • I don't want to file this story as disaster porn, but so far it hasn't been anything I could describe as helpful. Ditto the comments. Double ditto the link and the comments there.

    Right now I have 17.10 running on a Lenovo and a Toshiba, and so far I haven't noticed any problems. Lack of evidence is no proof of the negative...

    Seems like my easy "response" is to hope that the next updates from Ubuntu take care of the problem (for extremely low values of care?). Unless it's already too late, in which case...


    • Not like Linux needs to shoot its reputation in the foot.

      You do understand, don't you, that Ubuntu != Linux. I run Fedora, and there's been no mention of this particular issue affecting Fedora, even though it's always very big on pushing out new kernels as quickly as possible. I don't know if either distro modifies the kernel before making it available, or if this isn't in the kernel itself but some support module, but AFAICT it's distro-specific. I do hope, of course, that it gets cleared up quickly.
      • by shanen ( 462549 )

        I certainly agree with you that there are many distributions, and I think that is one of the best aspects of Linux. Monolithic thinking is anti-freedom. Check my sig.

        However whenever a major distro looks bad, all of Linux catches some shade. I still blame the financial models, but been there, done that, no one's interested in such crazy ideas as alternative possibly even better financial models.

  • What the hell in the operating system needs to write data to the BIOS chip? I'd love to hear anyone's reasoning behind why that's remotely necessary.
    • by bws111 ( 1216812 )

      Update the BIOS on managed systems. Set things in NVRAM (boot order, secure boot keys, etc).

      • Is there a man page for the Linux program that sets things in NVRAM? I don't recall seeing that anywhere.

        • by bws111 ( 1216812 )

          Don't know about a man page, but the /sys/firmware/efi/efivars filesystem contains the efi nvram. Read and write.

        • by bws111 ( 1216812 )

          To be clear, any program that can write files can set things in nvram through that filesystem (the data does need a 4 byte attribute prepended to it). The only program I can think of that specifically changes nvram is efibootmgr (there is a man page for that), but even that is just using the efivars filesystem.

  • Instead of doing one task very well, it's trying to do everything. With predictable results..
  • I've lost confidence in Ubuntu. Canonical seems increasingly user-hostile. And in my subjective opinion - reinforced by this story - their technical quality has been declining for a while.

    So what's the alternative?

    My Docker containers are already based on Alpine, and running atop ECS, which is based on Amazon Linux. But I still need cloud VMs and bare metal servers. One thing I really appreciate about Ubuntu it's the ease of running the same OS on my servers and on my Thinkpad laptop.

    *BSD is out because af

  • HP also has Insyde BIOS in their laptops and newer laptops usually works perfectly with Linux. Is there any reports of problems with HP?

Today is a good day for information-gathering. Read someone else's mail file.