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.

Kommentare

22 Antworten zu „Schwierige Reparatur von BootHole“

  1. Avatar von Psiana

    Ich hoffe, mein Rechner bootet heute, sonst muss ich auf Timeshift zurückgreifen und hoffen, grub damit downgraden zu können.

    1. Avatar von Ferdinand

      Genau für solche Fälle ist ja Timeshift gedacht. Da dort ein älterer GRUB im Abbild ist, sehe ich da kein Problem.

  2. Avatar von chris_blues

    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.

    1. Avatar von Ferdinand

      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.

    2. Avatar von 0byte
      0byte

      Es ist nicht verkehrt so ein Notfall Usb Stick immer parat zu haben.

  3. Avatar von Marco Krieger

    Da bin ich aber froh, das ich auf meinem Laptop Manjaro installiert habe, weil Mint, Ubuntu und Debia… https://t.co/d1f3ZOTwK8

    1. Avatar von Klopsesser
      Klopsesser

      Jaja, wir werden (daran) sowieso alles sterben…

    2. Avatar von tuxnix
      tuxnix

      So viel mal zur angeblichen Instabilität von Rolling Release Distributionen 🙂

      1. Avatar von 0byte
        0byte

        Bei Arch kam heute das Update. Habe zwei Rechner aktualisiert, mit EFI ohne Secure Boot und mit Bios. Beide booten 👍😇

        1. Avatar von tuxnix
          tuxnix

          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.

          1. Avatar von 0byte
            0byte

            Ich denke Debian ist eine viel grössere Distribution als Arch.

          2. Avatar von Ferdinand

            Vor allem viel mehr unterstützte Architekturen.

  4. Avatar von Nick
    Nick

    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.

    1. Avatar von Klopsesser
      Klopsesser

      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)

  5. Avatar von Klopskind1
    Klopskind1

    Wird heißer gekocht als gegessen. Jede Distro wird zeitnah nen Fix anbieten.

  6. Avatar von Sven
    Sven

    BootRepairDisk hat bei mir geholfen

  7. Avatar von Marius
    Marius

    Fedora hat keine Probleme, weil es noch kein Update zu Stable gab 😀

  8. Avatar von Andree
    Andree

    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.

    1. Avatar von der alte Ösi
      der alte Ösi

      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.

      1. Avatar von Klopskind1
        Klopskind1

        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.

        1. Avatar von Ferdinand

          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*

        2. Avatar von 0byte
          0byte

          Welche Stärken hat Arch auf einem Server?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert