Canonical erinnerte an die im Oktober veröffentlichte Ubuntu 17.10-Distribution und
versteckte den Link zur Download-Site . Der Grund war ein
kritischer Fehler mit BIOS-Schäden in einigen Lenovo Laptop-Modellen und einem Acer-Modell. Eine vollständige Liste der betroffenen Modelle wird derzeit aktualisiert und aktualisiert.
Eine Beschädigung des BIOS äußert sich darin, dass die neuen Einstellungen nicht mehr gespeichert werden können und der Laptop nach einem Neustart mit den alten Einstellungen beginnt.
Erschwerend kommt hinzu, dass das Booten von einem USB-Stick unterbrochen wird, weil USB nicht erkannt wird.
Gemessen an der Beschreibung des Fehlers scheint dies nach der Aktivierung von Intel-SPI-Treibern im Kernel zu geschehen. Anscheinend sind diese Treiber noch nicht vollständig entwickelt und können nicht auf Benutzersystemen verwendet werden.
Um dieses Problem zu umgehen, können Sie versuchen, die Intel-SPI-Treiber zu deaktivieren. Die Beschreibung des Fehlers besagt, dass die Konsequenzen solcher Aktionen minimal sein werden: "Es ist unwahrscheinlich, dass jemand wirklich etwas tut, das diesen Treiber erfordert."
Liste der betroffenen Laptop-Modelle:
- Lenovo B40-70
- Lenovo B50-70
- Lenovo B50-80
- Lenovo Flex-3
- Lenovo Flex-10
- Lenovo G40-30
- Lenovo G50-70
- Lenovo G50-80
- Lenovo S20-30
- Lenovo U31-70
- Lenovo Y50-70
- Lenovo Y70-70
- Lenovo Yoga Thinkpad (20C0)
- Lenovo Yoga 2 11 "- 20332
- Lenovo Z50-70
- Lenovo Z51-70
- Lenovo Ideapad 100-15IBY
- Acer Aspire E5-771G
Wie bereits erwähnt, wächst die Liste.
In den Fehlerkommentaren wird auch das Toshiba L50B-23G erwähnt.
In vielen Foren beschweren sich Benutzer über dieses Problem, da viele Laptops keine CD-ROM-Laufwerke haben und daher nicht mehr von einer anderen Distribution booten können.
Besonders viele Beschwerden in Lenovo Foren. Dies ist besonders unangenehm, da häufig Lenovo ThinkPad-Laptops für die Arbeit mit Linux empfohlen werden und Canonical sie auf der Offline-Liste der offiziell unterstützten Geräte hat.
In früheren Versionen von Ubuntu tritt kein Fehler auf.
Theoretisch kann das BIOS geflasht und in den ursprünglichen Zustand zurückversetzt werden (z. B. mit dem Programmierer), dies ist jedoch eine nicht triviale und leicht riskante Prozedur. Darüber hinaus hat nicht jeder Benutzer einen Programmierer. Daher kann man die starke Unzufriedenheit derer verstehen, die mit diesem Problem konfrontiert sind und den Laptop nicht laden können. "Das ist inakzeptabel. Im Moment hat sich mein Lenovo G50-80 in einen Baustein verwandelt", schrieb eines der Opfer in einem Kommentar zu einem Fehler auf der Canonical-Website.
UPD Anmerkung von Benutzer r0mik in den Kommentaren zum Artikel: „Das BIOS verschlechtert sich nicht“ im wörtlichen Sinne - der SPI-Flash-Chip ruht auf der Aufzeichnung. Anscheinend geschieht dies über das oben erwähnte Kernelmodul, da es das einzige ist, das zu solchen Aktionen fähig ist (dafür wurde es auch geschrieben). Gerade weil SPI Flash für die Aufzeichnung hardwaresperrend ist, funktioniert kein Rollback auf die Standard-BIOS-Einstellungen, da die Einstellungen in SPI Flash gespeichert sind. Der Programmierer wird auch nicht helfen. Nur ein physischer Austausch der Mikroschaltung hilft ...
Canonical arbeitet jetzt aktiv mit Lenovo zusammen, um die wahre Ursache des Problems zu finden und den Patch zu veröffentlichen. Für Ubuntu 17.10 werden neue Images mit einem aktualisierten Kernel vorbereitet, der das BIOS bei Neuinstallationen nicht beschädigt.
Leider helfen die neuen Images niemandem, der Ubuntu 17.10 bereits installiert und die BIOS-Firmware beschädigt hat. Ein Extremfall besteht darin, einen Laptop zur Reparatur mitzunehmen, um das Motherboard zu ersetzen. Wenn der Laptop noch geladen ist, können Sie eine solche
Problemumgehung ausprobieren, die in den technischen Support-Foren von Lenovo angeboten wird.
Dieser Benutzer konnte auch die neuen BIOS-Einstellungen nicht speichern und konnte nicht mehr über USB booten. Zuerst überprüfte er die EFI-Startsequenz. Dies erfolgt mit folgendem Befehl:
efibootmgr -vIn seinem Fall sah die Startsequenz folgendermaßen aus:
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0002,2001,2002,2003
Boot0001* antergos_grub HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(\EFI\antergos_grub\grubx64.efi)
Boot0002* Windows Boot Manager HD(1,GPT,f128f12b-fa3e-45b1-b5c9-f03c328498cb,0x800,0x64000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)RC
Boot2001* EFI USB Device RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network RCDaraus folgt, dass grubx64.efi aus dem Verzeichnis antergos_grub als erstes in irgendeiner Weise und nur von der angegebenen Festplatte geladen wird.
Es ist logisch anzunehmen, dass wir den Download steuern können, indem wir den Inhalt des Ordners antergos_grub ändern. Er ersetzte einfach den Inhalt dieses Ordners durch den Inhalt des
rEFInd- Download-Manager-Pakets und benannte refind_x64.efi in grubx64.efi um. Nach dem Laden des Laptops wird das Standard-Startmenü für rEFInd angezeigt.