
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.
Schreibe einen Kommentar