Ubuntu 17.10 Temporarily Pulled Due To A BIOS Corrupting Problem (phoronix.com)

That ain't right! by Anonymous Coward · 2017-12-20 06:08 · Score: 4, Insightful

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!

Re:That ain't right! by omnichad · 2017-12-20 06:12 · Score: 1

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:That ain't right! by Anonymous Coward · 2017-12-20 06:18 · Score: 2, Insightful

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.
Re:That ain't right! by omnichad · 2017-12-20 06:20 · Score: 2

In this case, at least one person involved was unable to resolve it by replacing the CMOS battery:
https://bugs.launchpad.net/ubu...
Re:That ain't right! by Immerman · 2017-12-20 07:32 · Score: 1

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've heard a couple companies do in fact make them)

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by drinkypoo · 2017-12-20 07:55 · Score: 1

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...

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Re:That ain't right! by Anonymous Coward · 2017-12-20 08:29 · Score: 1

TL;DR
Re:That ain't right! by Anonymous Coward · 2017-12-20 08:39 · Score: 1

I can only read when proper paragraphs are used, you insensitive clod!
Re:That ain't right! by omnichad · 2017-12-20 08:57 · Score: 1

A half-hour? Just drain the caps with a few presses of the power button.
Re:That ain't right! by Immerman · 2017-12-20 09:25 · Score: 1

I've looked at those before, and it does look like a nice drive, but has tons of features I don't have any use for and is ridiculously expensive ($45 for an 8GB drive?). Meanwhile a $5 16GB drive does everything I need, except for lacking a $0.10 write protect switch, and is cheap enough that I don't care about losing it.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by Immerman · 2017-12-20 09:37 · Score: 1

Sadly, I recently discovered that those only offer software-based protection - i.e. they tell the computer "don't write to me", but rely on the software to honor that request, and don't actually do anything to protect your data from a malfunctioning or compromised computer. Unlike write-protect tabs on floppy disks for example, where the drive would simply return an error to the OS if you tried to write to a protected disk.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by Immerman · 2017-12-20 09:38 · Score: 1

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.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by eneville · 2017-12-20 09:50 · Score: 1

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.

--
Why UNIX?
Re:That ain't right! by Immerman · 2017-12-20 10:38 · Score: 1

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 trivial in comparison?
For bonus points - of those who resort to flashing their BIOS to fix a problem - how many of the problems do you suppose are caused by BIOS corruption that could have been prevented with hardware write protection?

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by sabri · 2017-12-20 11:54 · Score: 1

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

--
I'm not a complete idiot... Some parts are missing.
Re:That ain't right! by Desler · 2017-12-20 13:35 · Score: 1

The problem is likely that USB drives with hardware write locks are made in much smaller production runs so the price is higher. It just comes with the territory for niche use cases.
Re: That ain't right! by Reverend+Green · 2017-12-20 17:26 · Score: 1

Nice wallotext!
Re:That ain't right! by MoarSauce123 · 2017-12-21 00:03 · Score: 1

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!"
Re:That ain't right! by Immerman · 2017-12-21 03:19 · Score: 1

But why is write-lock a niche use case? In the floppy days everybody I knew used the lock tabs on a regular basis - and if anything the reasons for doing so have increased dramatically. Why should you risk getting infected by whatever's on your friend/coworkers/etc. computer just to give them a copy of some file or other? Or risk your backups when you want to retrieve something? Same thing with early USB drives - using the write-lock was just common sense. Then they just sort of disappeared.
I also suspect a lot of the price has to do with the 256-bit hardware encryption and other limited-use features that increase the sophistication of the hardware. A simple toggle-switch and "if lock line is high, report error, else write data" line in the embedded software should cost well under a dollar to add.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by eneville · 2017-12-21 06:21 · Score: 1

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.

--
Why UNIX?
Re:That ain't right! by Immerman · 2017-12-21 06:39 · Score: 1

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.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:That ain't right! by fustakrakich · 2017-12-21 13:33 · Score: 1

That doesn't sound possible. Write protection on a USB is still done in software, and that particular product is a *black box*.

--
“He’s not deformed, he’s just drunk!”

which is to blame Linux or Lenovo? by Dorianny · 2017-12-20 06:11 · Score: 1

Anybody know if the issue is a bug in the driver code or is the driver inadvertently exposing a faulty bios implementations

Re:which is to blame Linux or Lenovo? by omnichad · 2017-12-20 06:17 · Score: 5, Informative

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.
Re:which is to blame Linux or Lenovo? by Hal_Porter · 2017-12-20 06:39 · Score: 5, Interesting

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
https://www.howtogeek.com/2263...

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.

--
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Re:which is to blame Linux or Lenovo? by Dorianny · 2017-12-20 07:06 · Score: 3, Interesting

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
Re:which is to blame Linux or Lenovo? by Junta · 2017-12-20 07:22 · Score: 1

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.

--
XML is like violence. If it doesn't solve the problem, use more.

Interestingly enough Win10 1709 did this by oobayly · 2017-12-20 06:16 · Score: 4, Interesting

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.

Re:Interestingly enough Win10 1709 did this by omnichad · 2017-12-20 06:23 · Score: 1

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.
Re: Interestingly enough Win10 1709 did this by oobayly · 2017-12-20 06:26 · Score: 1

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.
Re: Interestingly enough Win10 1709 did this by oobayly · 2017-12-20 06:28 · Score: 1

Maybe, but I was pretty lax about keeping Linux up to date, and hadn't used it a great deal so the configuration was unlikely to have changed recently.
Re:Interestingly enough Win10 1709 did this by Desler · 2017-12-20 07:07 · Score: 1

At least it wasn’t an HP laptop. It can always be worse...

The timing. by Anonymous Coward · 2017-12-20 06:18 · Score: 1

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

OS-level Updates by nuckfuts · 2017-12-20 06:38 · Score: 2

These days, "BIOS-level" upgrades ARE "OS-level" upgrades. UEFI even has its own shell.

Case in point:

I recently purchased a Dell PowerEdge server to run VMware's ESXi hypervisor. Before installing ESXi, I wanted to update the BIOS to the most current version. On Dell's site, I could not a "BIOS-level" update package, only "OS-level" ones. I talked to Dell, and to my surprise, the answer was to run their Windows executable from the BIOS shell.

Re:OS-level Updates by Junta · 2017-12-20 07:15 · Score: 1

UEFI even has its own shell.
Well, it's an *option* to use some of the space to host a UEFI shell, though not all vendors bother to do so. It's basically like installing dos in your BIOS rom. UEFI shell is basically the same thing as command.com: an extremely thin layer on top of firmware calls. Of course that USEFI can have network drivers and filesystem drivers whereas BIOS only ever had the concept of block device access and access MBR as a program baked in.
When it comes to servers, increasingly the expectation is that you use the management port to apply the update remotely unless you make a boot disk (usually linux base) or use the operating system to do the update.

--
XML is like violence. If it doesn't solve the problem, use more.
Re:OS-level Updates by Anonymous Coward · 2017-12-20 07:21 · Score: 1

Dell's BIOS updates are hybrid executables that work from Windows, FreeDOS and UEFI Shell/UEFI Setup on desktops. They can also be used to directly update from Linux using the UEFI Capsule Update specification.
Re:OS-level Updates by Hal_Porter · 2017-12-20 08:01 · Score: 1

I wonder how they do that?
FreeDos and Windows would be easy - you'd have a Win32 PE file where the DOS exe stub exe was the FreeDos update exe. Same with FreeDos and UEFI because UEFI uses PE files. So you have a PE file for the UEFI code with the FreeDos code as the stub file.
UEFI uses PE files but the API is completely different to Win32. They must have worked out some way to mix MZ EXE, Win32 x86 PE and UEFI PE into one file.

--
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Re:OS-level Updates by Hal_Porter · 2017-12-20 08:13 · Score: 2

Oops. the link to how PE files contain a Dos exe stub didn't work
https://upload.wikimedia.org/w...
Originally this just printed "This program requires Microsoft Windows". Of course if you have a Dos version of something you can make that the stub.
The problem is that there's no documented way to combine two PE files for different APIs - Win32 and UEFI. It's also not really clear to me what the UEFI app should be built for - you can have native x86, native x64 or EBC - a byte code format.
Even though most Windows installations are 64 bit they can still run x86 code, so that seems safe. With UEFI you have to either match the native architecture or use EBC. And it's not clear how many UEFI bioses are x86, x64 or EBC capable. Then again I suppose Dell would know what would work. Still combining Win32 and UEFI code into one PE file seems like it would need a trick I don't know.

--
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Re:OS-level Updates by TheRaven64 · 2017-12-20 08:50 · Score: 1

There may not be an official way, but if your possible systems are all from a limited set and you're really only having to differentiate between Windows and UEFI or DOS and Windows (the other poster pointed out that there's an official way of having both DOS and Windows entry points), then it should be possible to find a system call that just provides information on both systems and has a return value that lets you tell them apart. You do this early and then jump to the relevant entry point.
Even more fun, there was recently a DARPA-funded program that recently worked out that there's a useful subset of both ARM and x86 that is entirely NOPs in the other. I don't remember if it's Turing complete, but it is definitely enough to write a little header that will branch to either the x86 entry point if run on x86 or the ARM entry point if run on ARM.

--
I am TheRaven on Soylent News
Re:OS-level Updates by Hal_Porter · 2017-12-20 09:38 · Score: 1

There may not be an official way, but if your possible systems are all from a limited set and you're really only having to differentiate between Windows and UEFI or DOS and Windows (the other poster pointed out that there's an official way of having both DOS and Windows entry points),
That was me

then it should be possible to find a system call that just provides information on both systems and has a return value that lets you tell them apart. You do this early and then jump to the relevant entry point.
The problem is that even though Windows and UEFI both use PE files, there are significant differences.
Windows applications use subsystem=2 for GUI and 3 for console
https://msdn.microsoft.com/en-...
UEFI applications uses subsystem=10
http://wiki.osdev.org/UEFI#Bin...
Also windows executables are .exe and UEFI applications are .efi
I.e. it's hard to build a single executable that would pass the subsystem and file extension checks to run on both Windows and UEFI. Which of course is by design - otherwise people would run executables on the wrong platform and brick it.
Here it seems like Dell just distribute a bunch of different executables. One for Windows/FreeDOS(.exe), one for Linux(.bin) and one for UEFI (.efi)
http://www.dell.com/support/ho...
You could have them share a data file if space is at a premium.
Though a Win32/UEFI polyglot may be possible I can't find one. And I'm not sure how it would work.
The one possibility would be if Terse Executable files can begin at something other than offset zero in a file. TE files are a sort of stripped down PE file with all the unnecessary crap removed from the PE headers.
http://wiki.phoenix.com/wiki/i...
But it seems unlikely UEFI executable loader code is willing to skip bytes endlessly until it sees a VZ signature.

--
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
Re:OS-level Updates by AmiMoJo · 2017-12-20 16:53 · Score: 1

That's a Dell thing, it's not part of the UEFI core spec. Some laptops from a few years back had a Linux OS in there to play DVDs and browse the web without booting Windows.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC

Isn't wonderful by DarkOx · 2017-12-20 06:40 · Score: 4, Insightful

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!

Progress!

--
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html

Re:Isn't wonderful by bws111 · 2017-12-20 06:58 · Score: 1

That happened over 20 years ago. Time to get over it.
Re:Isn't wonderful by Junta · 2017-12-20 07:17 · Score: 1

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.

--
XML is like violence. If it doesn't solve the problem, use more.
Re:Isn't wonderful by Anonymous Coward · 2017-12-20 07:38 · Score: 1

Or, time to fix it?
Re:Isn't wonderful by Anonymous Coward · 2017-12-20 08:04 · Score: 1

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.
Re:Isn't wonderful by TheRaven64 · 2017-12-20 08:55 · Score: 1

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.

--
I am TheRaven on Soylent News
Re:Isn't wonderful by bws111 · 2017-12-20 08:57 · Score: 1

Updateable BIOS's have been around since at least the mid 90s. BIOS has not been on a ROM since then.
Re:Isn't wonderful by AmiMoJo · 2017-12-20 16:51 · Score: 1

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.

--
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
Re:Isn't wonderful by thegarbz · 2017-12-21 01:50 · Score: 1

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.
Re:Isn't wonderful by TheRaven64 · 2017-12-22 03:48 · Score: 1

BIOS updates from as long as I can remember involved a program running on an OS. Some came with a FreeDOS bootable floppy image, some just a DOS program. Later ones were installed automatically from within Windows when you installed the motherboard drivers as part of Windows update, or via a similar procedure in Linux. There's nothing specific to EFI about having the OS install firmware updates.

--
I am TheRaven on Soylent News

Re:I remember by DCFusor · 2017-12-20 07:04 · Score: 1

Me too. This sort of thing should be brought back. Not that it will, since the current way allows vendors to "fix" sloppy code later without it being such a burden on customers, and save the price of a jumper - and physical access to one, to put into profit. And obviously, those who desire backdoors into our stuff like it as it is. Methuselah wasn't always wrong, you know.

--
Why guess when you can know? Measure!

Re:I remember by Junta · 2017-12-20 07:18 · Score: 1

I remember a problem with a modem I bought back in the day, that was solved in a firmware update.

The firmware update was a package in the mail with a new chip and a chip puller.

Note having one of these devices was pretty neat. If I had a few thousand of them however....

--
XML is like violence. If it doesn't solve the problem, use more.

Another kernel bug did something similar by iampiti · 2017-12-20 07:19 · Score: 1

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.

Re:Another kernel bug did something similar by iampiti · 2017-12-20 07:20 · Score: 1

Correction: It wasn't actually a kernel bug, it was a bug of the cdrom's firmware
Re:Another kernel bug did something similar by AvitarX · 2017-12-20 10:05 · Score: 1

I'd argue that it was both.
Sending junk commands isn't exactly something I'd think the kernel should do.

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg

We need to stop by ReneR · 2017-12-20 07:22 · Score: 1

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, ...

Recurring problem with them. by Fly+Swatter · 2017-12-20 07:27 · Score: 1

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 :/

Separation of concerns by lucasnate1 · 2017-12-20 07:43 · Score: 1

Why has the world forgotten it?

--
Avantgarde Hebrew science fiction

Re:Open SORES Infects Again by F.Ultra · 2017-12-20 07:51 · Score: 1

Sure? https://answers.microsoft.com/...

That's not the same problem by drinkypoo · 2017-12-20 07:52 · Score: 3, Informative

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...)

--
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"

I updated to 17.10 on my Yoga 2 pro, am I fucked? by wfj2fd · 2017-12-20 08:03 · Score: 1

I've had no problems so far, but will this brick my machine in the near future?

Re:Why the hell is it even touching the BIOS at al by Swave+An+deBwoner · 2017-12-20 08:09 · Score: 1

127.0.0.1 www.ubuntu.com

DUAL BIOS Motherboards by Darkk · 2017-12-20 08:17 · Score: 2

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.

So is there any test or list of affected models? by shanen · 2017-12-20 08:41 · Score: 1

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.

Me? I still lament that Linux was unable to seize the golden opportunity of Windows 8. Most of my machines run Windows 10 these days, alas...

--
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.

What even is that? by slashmydots · 2017-12-20 08:44 · Score: 1

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.

Re:What even is that? by bws111 · 2017-12-20 09:22 · Score: 1

Update the BIOS on managed systems. Set things in NVRAM (boot order, secure boot keys, etc).
Re:What even is that? by feenberg · 2017-12-20 11:37 · Score: 1

Is there a man page for the Linux program that sets things in NVRAM? I don't recall seeing that anywhere.
Re:What even is that? by bws111 · 2017-12-20 12:13 · Score: 1

Don't know about a man page, but the /sys/firmware/efi/efivars filesystem contains the efi nvram. Read and write.
Re:What even is that? by bws111 · 2017-12-20 13:24 · Score: 1

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.

Re:Short terminals after battery removal by Immerman · 2017-12-20 09:27 · Score: 1

Don't forget disconnecting from power and leaving it switched ON for an extended period, to make sure to drain any lingering charge. That's the bit many people often forget, since it usually doesn't matter, except when the ghost of random chance decides to $#@! with your day.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.

BIOS now has same problem as with systemd. by CptLoRes · 2017-12-20 09:34 · Score: 1

Instead of doing one task very well, it's trying to do everything. With predictable results..

Re:So is there any test or list of affected models by techno-vampire · 2017-12-20 09:37 · Score: 1

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.

--
Good, inexpensive web hosting

Re:Short terminals after battery removal by fisted · 2017-12-20 09:46 · Score: 1

Don't forget disconnecting from power and leaving it switched ON for an extended period

Or, you know, push the power button once and see the fans consuming what little remains in the capacitors so you don't have to wait for an extended period

--
CLI paste? paste.pr0.tips!

Re:Why the hell is it even touching the BIOS at al by nnet · 2017-12-20 09:49 · Score: 1

::1 www.ubuntu.com

FTFY.

Re:Christopher Reimer, dead at 48 by nnet · 2017-12-20 09:57 · Score: 1

Florida's goalie?!?

Re:I remember by gweihir · 2017-12-20 10:00 · Score: 1

The utterly pathetic thing is that most SPI flash actually directly supports such a jumper. The mainboard manufacturers just likely have found out that people are too stupid to handle jumpers and left it out.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.

Re:Why the hell is it even touching the BIOS at al by Swave+An+deBwoner · 2017-12-20 10:17 · Score: 1

You ought to fix that for Ubuntu.com first; their nameservers don't seem to offer an IPv6 (AAAA) RR.

Obligatory :-) included at no extra charge.

Re:Short terminals after battery removal by Immerman · 2017-12-20 10:28 · Score: 1

That drains the power capacitors - but not necessarily charge stored in the electronics themselves. In DRAM for example, every bit is implemented as an independent capacitor. Other devices, even those that aren't intended to act as capacitors may also be capable of storing an internal charge with unpredictable lingering effects.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.

Re:I updated to 17.10 on my Yoga 2 pro, am I fucke by ilsaloving · 2017-12-20 10:50 · Score: 1

Just never reboot your machine ever again. :)

Re:So is there any test or list of affected models by shanen · 2017-12-20 11:05 · Score: 1

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.

--
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.

Re:Why the hell is it even touching the BIOS at al by nnet · 2017-12-20 11:24 · Score: 1

Fix what? See above.

Re:I remember by DCFusor · 2017-12-20 15:57 · Score: 1

Depending on the eeprom, you might need a transistor or two in order to turn Vpp on and off - usually around 12v. And of course, some UV lamp to erase one first. The thing is, it had to be a deliberate act to change that stuff - these days a coffee shop or a PC shop could do it as a service in between replacing broken phone screens.
Now, there's zero opportunity cost for some cracker to try and mess up your stuff.
If you want to, say, steal my tools, you have to show up - and I might shoot you - there's cost of getting here, and there's risk to you in trying.
With the internet, there's no cost to get here, and little risk of attribution. For the end user, the use of flash is a very bad tradeoff made for you by someone who doesn't take responsibility for the total costs.

--
Why guess when you can know? Measure!

Re: I remember by Reverend+Green · 2017-12-20 17:40 · Score: 1

But how can the vendors be Agile(tm) if they can't release bug-riddled crapware and let their customers serve as free QA?

confidence game by Reverend+Green · 2017-12-20 18:02 · Score: 1

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 afaik it cannot run Docker. No, I'm not fucking giving up my containers. They are incredibly useful for my job.

Mint is for dopes.

Slackware was fun 20 years ago when I was just learning. Seems like it would be an incredible pain to use it for production work.

CentOS and Fedora have always been a little unpleasant to work with. But maybe worth another look.

I've never actually tried Alpine outside a container. So it's a possibility I guess.

Serious question for people who have abandoned Ubuntu: What did you switch to? Was it worth the hassle?

Re:confidence game by Per+Wigren · 2017-12-20 19:03 · Score: 1

Debian.

--
My other account has a 3-digit UID.

HP Laptops with Insyde BIOS, affected or not? by deepclutch · 2017-12-20 21:11 · Score: 1

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

--
move to FOSS,save ur nation's resources.

Re: I remember by DCFusor · 2017-12-21 12:14 · Score: 1

Would mod funny if it weren't true and kinda sick (and well, I'm posting on this one)...insightful? Reality-based? Truly, it's about bucks. If we somehow made it clear we'd pay enough more for that write enable jumper (and the newly required increased support BS) - it'd be there, bet on it. And after awhile, it wouldn't need any more support than R&Ring an SD card - people do eventually learn the simple stuff if there's a benefit.

--
Why guess when you can know? Measure!

Re: Short terminals after battery removal by bohan · 2017-12-22 14:24 · Score: 1

Did you mean SRAM?

Re: Short terminals after battery removal by Immerman · 2017-12-23 16:23 · Score: 1

No, SRAM uses a bistable flip-flop which is stable so long as power is supplied, an - DRAM actually needs an external memory refresh circuit to regularly read/write the stored data before the capacitors discharge so much that 1s and 0s can't be reliably distinguished. https://en.wikipedia.org/wiki/...

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.

Slashdot Mirror

Ubuntu 17.10 Temporarily Pulled Due To A BIOS Corrupting Problem (phoronix.com)

90 of 167 comments (clear)