Bei dem Versuch, mit einer neuen Grub-Version die Sicherheitslücke BootHole zu stopfen, melden Anwender verschiedener Distributionen Systeme, die nach dem Update nicht mehr hochfahren. Dabei spielen, wie es aussieht, unterschiedliche Umstände eine Rolle. Zu den betroffenen Distributionen zählen Ubuntu, Debian, Linux Mint, Red Hat und CentOS. Fedora dagegen scheint nicht betroffen.
Red Hat, aber nicht Fedora
Bei Red Hat wurde ein Update für GRUB und den Kernel angeboten, was bei aktualisierten Systemen gleich nach den POST-Meldungen und noch vor GRUB zum Hängen der Systeme führte. Manchmal half das Ausschalten von Secure Boot, um den Rechner hochfahren zu lassen. Wenn das nicht funktioniert, muss in einer [wiki title=”Chroot”]Chroot[/wiki] GRUB wieder de-aktualisiert werden. Der Fehler wurde zunächst in grub2-efi-x64 vermutet, was sich aber als falsch herausstellte. Schuld war in Wirklichkeit das Paket shimx64.efi.
Debian Testing noch verwundbar
Debian hat ein ausführliches Statement zu BootHole veröffentlicht, aus dem bereits hervorging, dass erwartet wird, dass Systeme nach den nötigen Updates nicht mehr starten könnten. Davon seien älterer Systeme bei Verwendung von BIOS anstatt UEFI sowie Dual-Boots mit Windows und Linux betroffen. Bei letzteren kann Linux den Systemstart verweigern.
Noch gestern Abend wurde für Debian Stable das GRUB2-Paket 2.02+dfsg1-20+deb10u2 freigegeben, dass das Problem behebt. Demnach sind Buster und Sid abgesichert, Bullseye, also der derzeitige Testing-Zweig dagegen nicht.
Ubuntu und Mint
Bei Ubuntu gibt es im Launchpad einen Bug-Report der dort derzeit 25 Rechner betrifft, die mit BIOS installiert wurden. Diese verweigern den Start mit der Meldung error: symbol `grub_calloc' not found und werfen den Nutzer in eine GRUB-Shell. Weitere Betroffene wendeten sich an die Plattform Ask Ubuntu, um das Problem zu lösen. Dort wurde untrer anderem Boot-Repair zur Behebung des Problems vorgeschlagen.
Offensichtlich war sich der Paketmanager dpkg im unklaren, wohin GRUB2 beim Update zu installieren sei. Als Lösung wurde in einer Chroot der Befehl dpkg-reconfigure grub-pc empfohlen, dem dann das korrekte Device zur Installation von GRUB2 mitgegeben werden muss.
Ubuntu auf allen Ebenen betroffen
Der Fehler betrifft zumindest Ubuntu 18.04 und 20.04. Auch von Azure, AWS EC2 und Ubuntu Server gab es gleichlautende Meldungen. Bei Linux Mint 20 machten Anwender die gleiche Erfahrung. Canonical hat Problem und derzeitige Lösung ausführlich im Wiki beschrieben.
Auch SUSE hatte ausführlich über BootHole berichtet, hier sind mir allerdings bisher keine Meldungen über nicht startende Rechner bekannt.
Also habe 2 Laptops und einen Desktop PC mit openSUSE Tumbleweed am laufen jeden Tag am Updaten.
Gestern auch Grub auf allen 3 Systemen ein Update gehabt alle 3 laufen keine Probleme bis jetzt.
Aber Tumbleweed ist doch eine ach so böse Rolling Distribution! Und dann auch noch Opensuse! [Ironie Modus aus]
Ich nutze selbst seit fast 20 Jahren Opensuse, früher Suse genannt, seit 2 Jahren Tumbleweed die und kann über keine Probleme berichten. Irgendwas müssen die Leute bei Opensuse bzw. Suse ja doch richtig machen.
Es gibt nicht das eine Linux, jede Distribution hat seine Stärken und Schwächen. Wie oft unterhalte ich mich in Foren mit Menschen und erzähle ihnen, das ich Arch auf einem Server laufen habe, die Reaktion ist oft verächtlich und misstrauisch. Weil viele nicht über den Tellerand hinaus blicken können.
Wenn du vermeiden möchtest, dass ich jeden Beitrag von dir gesondert freigeben muss, wäre eine Möglichkeit, bei einem Nick und einer IP zu bleiben. *hint*
Welche Stärken hat Arch auf einem Server?
Fedora hat keine Probleme, weil es noch kein Update zu Stable gab 😀
BootRepairDisk hat bei mir geholfen
Wird heißer gekocht als gegessen. Jede Distro wird zeitnah nen Fix anbieten.
Warum wollen alle nur so schnell aktualisieren? Die zugrundeliegenden Sicherheitslücken sind lediglich theoretischer Natur, während ohnehin Rootrechte bzw. ein physischer Zugriff notwendig wäre um das auszunutzen. Die Wahrscheinlichkeit ist sehr groß das weder das eine noch das andere in den nächsten Jahren stattfindet. Und nicht nur wegen der schnellen Updates, sondern gänzlich ohne diese. Ich würde noch einige Zeit warten bis die ganzen Nebenwirkungen ausgebügelt sind, ehe ich mein System oder viele weitere reparieren muss. Schliesslich sind GRUB, systemd oder auch der Linux-Kernel kritische Komponenten, die man nicht einfach so sofort drüber bügelt.
Das sehe ich auch so!
Jedes Jahr so um diese Zeit herum kommen doch derartige Horrormeldungen, die m.M.n. nur den Zweck haben ein mehr oder weniger großes Sommerloch zu stopfen.
Also: L+L (lesen und lachen)
Da bin ich aber froh, das ich auf meinem Laptop Manjaro installiert habe, weil Mint, Ubuntu und Debia… https://t.co/d1f3ZOTwK8
Jaja, wir werden (daran) sowieso alles sterben…
So viel mal zur angeblichen Instabilität von Rolling Release Distributionen 🙂
Bei Arch kam heute das Update. Habe zwei Rechner aktualisiert, mit EFI ohne Secure Boot und mit Bios. Beide booten 👍😇
Als Rolling Realise Distribution ist es für Arch Linux völlig normal ein Kerlelupdate und ein Grub2 Update einzuspielen. Man dürfte auch genug Tester für das core Repository haben um die Stabilität sicherzustellen.
Für Debian ist das aber ein Sonderfall und ich vermute, dass man nur ungern an diesen Stellen zwischendurch etwas ändert und deshalb für so einen Sonderfall dann nicht genügend Tester zu Verfügung hat.
Ich denke Debian ist eine viel grössere Distribution als Arch.
Vor allem viel mehr unterstützte Architekturen.
Ich hab gerade meinen Laptop bemühen müssen, um mir einen Boot-Stick mit Debian zu bespielen. Nicht schön, da ist mir heute morgen allerhand Zeit durch die Lappen gegangen, die ich anderweitig hätte nutzen können…
Schon blöd, so ein Update rauszuhauen, was dann eine Menge Rechner nicht mehr starten läßt. Kommt einem vor, als wäre es mit glühender Nadel gestrickt worden. Dabei war doch allerhand Zeit da, ein sauberes Update vorzubereiten oder? Wie ich das verstanden habe, ist die Lücke doch schon länger bekannt, so daß alle betroffenen Distributoren genug Zeit haben einen gesunden Fix herauszubringen…
Naja, jedenfalls nachdem mein System wieder hochgefahren war, bot es mir auch gleich ein neues Update für grub2 an, jetzt scheint die Kiste wieder zu starten.
Das Problem ist seit April bekannt. Zur Ehrenrettung der Entwickler sei gesagt, dass GRUB mit unterschiedlichster Hardware in verschiedenen Einsatzszenarien und mit BIOS und UEFI mit und ohne Secure Boot klarkommen muss. Das konnte wohl nicht alles abgedeckt werden.
Es ist nicht verkehrt so ein Notfall Usb Stick immer parat zu haben.
Ich hoffe, mein Rechner bootet heute, sonst muss ich auf Timeshift zurückgreifen und hoffen, grub damit downgraden zu können.
Genau für solche Fälle ist ja Timeshift gedacht. Da dort ein älterer GRUB im Abbild ist, sehe ich da kein Problem.