Canonical stopt Ubuntu 17.10-distributie tijdelijk na meldingen bios-corruptie

Canonical raadt momenteel gebruikers af Ubuntu 17.10 te installeren. De organisatie heeft de distributie gestaakt, omdat de uitvoering op bepaalde Lenovo-laptops de bios kan corrumperen en instellingen daardoor niet meer kunnen worden opgeslagen.

Canonical werkt aan een fix en als die eenmaal klaar is, dan zal de organisatie Ubuntu 17.10 weer online zetten. Canonical heeft op de downloadpagina van Ubuntu een melding gezet dat de download van de meest recente versie 'ontmoedigd' wordt en verwijst daarbij naar een pagina over de bug.

De bug treft veel modellen van Lenovo en enkele Acer-laptops, zo blijkt uit de lijst op de bug-pagina. De bug komt door incompatibele spi-drivers van Intel, zo zegt Canonical. Door die drivers te deactiveren, is het mogelijk om instellingen in de bios weer op te slaan. Op het moment dat de fix in Ubuntu 17.10 zit, zal Canonical de download weer online zetten.

Reacties (46)

[nandervv]

Een ode aan UEFI, die ervoor zorgt dat OS-en überhaupt in de buurt van de BIOS moeten komen qua instellingen...

[HollowGamer]

Precies, dit lijkt me echt een probleem met de (U)EFI. Er zijn genoeg bugs hierin geweest:
- Te veel entries in een bepaalde table zorgde voor crashes/brick
- Fabrikanten die EFI bewust/onbewust misbruiken en daardoor problemen krijgen bij updates/NIX*
- Het niet volgen van /boot/efi paden op de juiste manier, waardoor booten niet lukt. Of helaas een 32-bit UEFI op een x64 gebruiken
- Niet updaten van beveiligingslekken op veel moederborden/systemen
- Enkel FAT32 ondersteunen voor EFI-partitie, ext* had ook prima gekund.

Nee, EFI brengt veel voordelen, maar ook ontzettend veel nadelen.
Het was tevens beter geweest als EFI veel minder onderdelen had gekregen.

[Joep Lunaar]

OT: ad 32bit UEFI
grub-efi-ia32 kan vanuit 32bits UEFI een x64 kernel laden en biedt bovendien een 64bits wrapper om de 32bit UEFI runtime services.

[HollowGamer]

Klopt, maar het is echt een gedoe. Zelf heb ik dit al eens aan de hand gehad bij een Intel x86 tablet, als je een 64-bit OS installeert, snapt deze niet altijd dat een 32-bit UEFI grub in dit geval moet worden gebruikt.
Gelukkig houdt Ubuntu hier nu rekening mee + meeste andere distro's ook, maar het blijft nogal vaag om hier perse een 32bit voor te gebruiken.

[sfranken]

- Enkel FAT32 ondersteunen voor EFI-partitie, ext* had ook prima gekund.

Dit is zoals het hoort. De specificatie zegt exFAT of FAT32, zie ook Wikipedia

[Reactie gewijzigd door sfranken op 24 juli 2024 10:00]

[HollowGamer]

Klopt, maar waarom zou je deze niet vrij moeten kunnen kiezen? Het is toch altijd de eerste partitie.
Dat er gekozen is voor FAT32 betekend niet dat hier perse iets fout aan is, maar het gaat erom dat deze gesloten standaard dat niet zomaar toelaat, tenzij je drivers/modules handmatig include.

[sfranken]

Omdat de code voor exFAT/FAT32 dusdanig stabiel is en breed gedragen is dat het in elk OS werkt. Ext(3|4) werkt alleen met Linux, en weer niet native onder Windows of macOS

[HollowGamer]

Zo stabiel zou ik FAT32 niet noemen helaas. Corruptie ligt nog altijd onder de loer, en komt/kan regelmatig voorkomen bijvoorbeeld bij een hard shutdown.

Het maakt niet zoveel uit welke FS het is - het zou als je enkel Windows boot ook prima NTFS of MacFS kunnen zijn op de Apple, het gaat erom dat je niet kan kiezen.
Tevens is ook het nadeel dat je met deze unencrypted partitie vrijwel alles kunt doen - ook eventueel met secure boot aan.

Tuurlijk kun je de HDD versleutelen via de BIOS, maar ik blijf de combinatie nog altijd vreemd vinden.

[sfranken]

Geen enkel FS vind een hard shutdown leuk, dat heeft niks met het FS te maken. De code van FAT is "volwassen", in tegenstelling tot APFS bijvoorbeeld. Bovendien heeft FAT weinig overhead

[wica]

Die UEFi bug is weer een andere.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147

Verder is is het jammer dan UEFI niet open is

[Xieoxer]

Ubuntu was/is niet de enige die kampt(e) met grote problemen deze weken. Het waren drukke weken voor systeembeheerders. Zo had Debian een 1,5 week geleden een nieuwe kernel released (3.16.4) voor Jessie. Als je een moederbord had waarop meerdere CPU’s gemonteerd op zat, dan zorgde de update ervoor dat je machine na een reboot niet meer opstarte. Je kreeg dan een kernel panic. Een groot issue in Debian land, omdat Debian wordt gezien als OS dat het meeste stabiele OS is. Ubuntu is gebaseerd op Debian en gebruikt vooral nieuwe technische knusjes wat pas jaren later op Debian te vinden is.

Dit is de bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883938

[Reactie gewijzigd door Xieoxer op 24 juli 2024 10:00]

[DigitalExorcist]

Juist daarom heb je een sandbox, Development, Quality en Production straatje ingericht om dit soort ongein te voorkomen...

[jochem4207]

En dan moet je geluk hebben dat al die omgevingen exact zelfde hardware hebben. Ben het helemaal met je eens maar ik het voelt als bijna onrealistisch wat erg is. (Ben wel student, weinig ervaring met grote it bedrijven?

[DigitalExorcist]

Nee dat is in de praktijk érg lastig inderdaad. Applicaties hebben vaak eigen requirements en dus hardwareconfiguraties, en leveranciers kunnen ook niet elk jaar dezelfde stepping van processoren of -generaties of moederborden garanderen. Dus nee, tenzij je in één keer een complete serverruimte kan aanschaffen met voorraad en alles erop en eraan, heb je allemaal verschillende hardware. Hoogstens van hetzelfde merk (en dus hetzelfde supportniveau).

Evengoed kun je dit soort risico’s verminderen (beloof NOOIT dat je iets kan voorkomen; dat is de Wet op Behoud van Ellende) door niet al je kritieke machines op dag 1 te patchen, en al helemaal niet tegelijk. Als er een versie *.0 uit komt, wacht dan altijd op een versie *.1 of *.0.1 of iets dergelijks. En patch een deel, test en accepteer dit een week (of 2), dan gefaseerd de rest.

Mocht je dan tegen een brakke kernel, Windows Update, driver, firmware of weet ik veel aanlopen, dan heb je even de tijd om dat te (laten) oplossen.

[rbr320]

Nee hoor je hebt helemaal gelijk. Voor een bedrijf dat software maakt in de orde van grote van enkele applicaties is het nog wel te doen om iedere release te testen op (vrijwel) alle configuraties die je bij een klant hebt staan. Maar voor een project ter grootte van Debian, een OS met miljoenen gebruikers met bijna evenzoveel hardware configuraties is dat realistisch gezien gewoon niet te doen. Debian test heel veel en heel uitgebreid en wordt daarom wat mij betreft terecht wel eens de meest stabiele Linux OS genoemd, maar dit is duidelijk een edge case waar je wel bij toeval tegenaan had kunnen lopen maar die ze blijkbaar niet geautomatiseerd testen.

[MrFax]

Ja maar wat als de hypervisor een kernel panic veroorzaakt?

[Olaf van der Spek]

Ook testen op een test machine voordat je die upgrade?

[wica]

Maar als je test systeem maar 1 socket heeft, dan had je dit probleem niet gehad.

Hi,
this seems to affect two-socket boxes.
Workaround is to set maxcpus=1 on the kernel command line.
Bernhard

[Olaf van der Spek]

Daarom testen met exact dezelfde hardware.

MS lijkt het met Windows eigenlijk beter te doen, geleidelijk deployen op nieuwe hardware configuraties en bijhouden wat wel en wat niet werkt. Alhoewel dat bijhouden dan soms qua privacy weer iets minder kan zijn.

[Reactie gewijzigd door Olaf van der Spek op 24 juli 2024 10:00]

[wica]

De meeste bedrijven hebben niet de exacte type HW. Naar mate ze groeien komt er HW bij.
Tenzij je de HW koopt alleen voor dat project ipv je huidige platform uit te breiden.
Als ik naar de kosten kijk, wordt er vaak voor optie 2 gekozen.

[Reactie gewijzigd door wica op 24 juli 2024 10:00]

[DigitalExorcist]

In de tijd dat ik nog met IBM xServers werkte was dat al een ding. Die typenummers vlogen je om de oren, specs ook, en veel applicaties hebben hun eigen requirements.

[_eXistenZ_]

Dan krijg je dit.

[DigitalExorcist]

Niet alles tegelijk upgraden. Sowieso verstandig. Als er een host onderuit gaat heb je je VM’s al elders draaien en fix je eerst je host voordat je de rest gaat doen. Lijkt mij dan.

[Blokker_1999]

En dan boot je gewoon weer met je oude kernel en ga je verder met je leven totdat de bug geplet is.

[Locke_]

Een groot issue in Debian land, omdat Debian wordt gezien als OS dat het meeste stabiele OS is.

Wij van wc eend...

[ArawnofAnnwn]

End of life in 2020. Niet echt een groot probleem om nu nog Jessie te draaien. Persoonlijk zou ik liever 7/Wheezy draaien, maar die support loopt volgend jaar al af.

[Qalo]

Vervelend voor Canonical (en dus blijkbaar ook voor Debian) dat dit gebeurt. Maar voor wat betreft Ubuntu 17.10 zou ik persoonlijk sowieso deze aan niemand aanraden, tenzij je thuis bent met Linux en dit alleen gebruikt om lekker mee te klooien. Als dagelijks systeem lijkt het me niet de meest juiste keuze. De ondersteuning is maar 9 maanden, en het is "maar" een tussenversie. Ga liever voor Ubuntu 16.04. Dat is een lang ondersteunde versie en ook iets betrouwbaarder. Zeker gaandeweg, na diverse updaterondes.

Ik hoop dat dit probleem zo snel mogelijk opgelost wordt.

[wica]

De 16.04 LTS heeft 5 jaar support.
De 17.* is meer edge.

Ik begrijp eigelijk ook niet waarom productie servers op 17.10 moeten draaien. Je gaat meestal een project aan voor 3 jaar +2 jaar verlenging. En dat valt meestal mooi binnen de LTS periode.

/edit
Dank je @Zidane007nl

[Reactie gewijzigd door wica op 24 juli 2024 10:00]

[Zidane007nl]

Ik denk dat je 16.04 LTS bedoelt. 17.04 is in eind januari EOL.
https://wiki.ubuntu.com/Releases

[TD-er]

Met Ubuntu is er elke 2 jaar een LTS versie, dus 12.04, 14.04, 16.04 etc....
Er is geen 17.04 LTS

[Zidane007nl]

Ik heb hetzelfde. Onlangs overgegaan naar een nieuwe laptop op mijn werk en de systeembeheerder heeft daar Ubuntu 17.04 op geïnstalleerd (volgens mij waren er problemen met 17.10). Mijn vorige laptop draaide 14.04 LTS en ik merk dat 17.04 gewoon minder stabiel is dan 14.04. Ook werken de fn toetsen niet en kan volume alleen aan of uit ...

[borft]

Wat bedoel je met minder stabiel? Crasht de laptop? Zeker voor nieuwere hardware zou ik nooit een 3.5 jaar oud besturingssysteem aanraden, ivm ontbrekende of verouderde drivers. Eventueel zou je 16.04 nog kunnen overwegen, dan heb je wel je LTS release. That said, op mijn workstation op werk zit ik op 17.10 (rolling upgrades gedaan), nog wel op een oudere kernel, maar wel al meer dan een jaar geleden dat ik gereboot heb, dus met de stabiliteit zit het wel goed dacht ik zo

[Zidane007nl]

Ja, Ubuntu blijft gewoon hangen. Zojuist en gisteren al een keer voorgekomen.
Net gekeken in syslog en het komt blijkbaar door een bug in de kernel.

[RavensAngel]

Fact! Was begonnen te ontwikkelen op ubuntu 17.04. Maar ben snel teruggekeerd naar 16.04. Had enorm veel problemen met tracker, crashes in gnome Shell, gewoon freezes, niet detecteren van meerdere schermen...
16.04 heeft voor mij geen problemen met zulke zaken. Hopelijk trekken ze dit allemaal snel recht.

[Toettoetdaan]

Jammer ik wilde net een VM opzetten met GUI, maar 17.04/16.10/16.04 zal ook wel werken

[timvisee]

Een VM moet prima werken, aan gezien je de hele boel virtualiseert. Dat zal je BIOS/UEFI niet bricken.

[Toettoetdaan]

Dat dacht ik ook, maar Ubuntu heeft de download van haar site gehaalt, dus ik moest hem binnen hengelen met een torrent of voor 16.04 LTS gaan. (Ik heb de torrent optie gekozen )

[Auredium]

Jammer maar zo te zien is Canonical niet direct verantwoordelijk voor de fout. Daarnaast is 17.10 ook vooral een testversie van Ubuntu. Liever dat dit nu wordt gevonden dan dat het zijn weg vond als bug in de komende LTS versie 18.04.

That said had ik verwacht dat Wayland juist de problemen zou veroorzaken in Ubuntu. Alhoewel die ook hier en daar wat issue veroorzaakt heeft.

[Deem]

Ach, Lenovo heeft er een handje aan om Linux installaties kapot te maken... Heeft waarschijnlijk alles te maken met hun Rootkits die in hun bios verwerkt zat. Na meerdere Incidenten leert Lenovo niets.

[Reactie gewijzigd door Deem op 24 juli 2024 10:00]

[Snake]

Die eerste link is gewoon het resultaat van Secure Boot. Aangezien bij Linux alles open-source is, is dit inderdaad een probleem als je geen eigen keys kunt importeren in de BIOS.

[qbig1970]

je blijft als OS-fabrikant toch af van BIOS van een laptopbouwer???
Wat moet Linux nou in het bios veugelen???

ik snap hem niet

[Verwijderd]

Volgens mij heeft dit iets te maken met UEFI, daar kan Linux weinig aan doen..

[Aardedraadje]

Als je de launchpad bug reports leest, wordt dat duidelijk. Het probleem zit hem in de Intel SPI drivers. De fix is ook het uitschakelen van deze drivers bij het compileren van de Kernel.

BIOS/UEFI, Flash, EEPROMS, ze kunnen allemaal aan een SPI bus hangen (een alternatief is bijvoorbeeld de I2C bus). Blijkbaar zit er een fout in de meegeleverde kernel's SPI drivers, waardoor er in combinatie met kwetsbare firmware op de UEFI een brick conditie ontstaat. Waarschijnlijk wordt er net een device verkeerd aangesproken, en kan de firmware hier niet goed mee omgaan. Het betreft dus eigenlijk ook een vulnerability in de UEFI van de getroffen systemen; elk kwaadwillend proces/OS met root/kernel rechten zou de UEFI kunnen beschadigen. De meeste getroffen system hadden overigens een Insyde UEFI.

[Reactie gewijzigd door Aardedraadje op 24 juli 2024 10:00]

[foxforgames]

Dit verklaard waarom mijn laptop zijn bios was gebrickt na het updaten naar 17.10.

[abbringm]

UEFI is te complex en nooit bedoeld voor de consument, maar om de commerciële belangen van fabrikanten te beschermen. Lullig voor de reputatie van Linux, maar gebruikers die Ubuntu op hun laptop hebben vluchten hooguit naar een Mac maar ik zie ze niet naar Windows gaan. De x86 hardware fabrikanten, Intel voorop, zijn hier vooral schuldig aan. UEFI had nooit geadopteerd moeten worden. Tijd om een beter, volledig transparant, alternatief te lanceren en breed te ondersteunen.