Schwierige Reparatur von BootHole
Screenshot von AWS auf Launchpad von Jeff Turner

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

Schwierige Reparatur von BootHole
4.5 4 votes
Article Rating

Verwandte Themen

4.5 4 votes
Article Rating
Abonnieren
Benachrichtige mich bei
Falls angehakt, wird ein MD5-Hash-Wert deiner E-Mail-Adresse an Gravatar.com übermittelt. Der Hash-Wert wird jedoch nicht veröffentlicht.
22 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments