Linux-Kernel bekommt "Blue Screens" mit QR-Code

Inhaltsverzeichnis

Der Linux-Kernel 6.12 wird nach derzeitigen Planungen einen QR-Code mit Fehlerinformationen darstellen können, wenn er die Weiterarbeit aufgrund eines extrem kritischen Fehlers sicherheitshalber komplett einstellt. Also ein Problem, das in der Unix-Welt als "Kernel Panic" und bei Windows als "Blue Screen" beziehungsweise "Blue Screen of Death" bekannt ist.

Der von Jocelyn Falempe entwickelte Code zur Darstellung des QR-Codes bei einer Panic ist das erste mit der Programmiersprache Rust realisierte Feature im offiziellen Kernel, das größere Nutzerkreise anspricht. Zumindest potenziell: Bei Mainstream-Linux-Distribution wird man solche QR-Codes aufgrund mehrerer Hürden wohl frühestens in einem halben Jahr zu sehen bekommen; noch ungewiss ist auch, mit wie vielen der bei x86-Systemen gängigen Grafikkarten das Ganze dann schon funktioniert.

Fedora Linux 42 soll diese Funktion im nächsten Jahr mitbringen. Sie ergänzt die QR-Fehlercodes, die Linux-Distributionen seit einem halben Jahr mithilfe von Systemd anzeigen können. Dieser Ansatz auf Betriebssystem-Ebene scheint laut zahlreichen Meldungen bereits das zu leisten, was der Linux genannte Kernel jetzt erst lernt. Tatsächlich aber ist Systemd bei einer echten Kernel-Panic machtlos; dafür kann es flexibler reagieren, wenn eine ansteht.

Unreifer Rust-Support ist eine langsam fallende Hürde

Die kleinste von drei Hindernissen, durch die Anwender QR-Code-Panics des Kernels nicht so bald zu Gesicht bekommen werden: der für die Erzeugung des QR-Codes zuständige Programmcode, der in Rust geschrieben wurde. Um ihn nutzen zu können, müssen Distributionen beim Bau ihrer Kernel daher den "Rust for Linux"-Support aktivieren. Viele sparen sich das bislang, weil das spezielle Compiler-Versionen erfordert, die nicht zu alt, aber auch nicht zu neu sein dürfen – und sich alle naselang mal ändern.

Das ist ab dem für den 16. oder 23. September erwarteten Linux 6.11 hinfällig: Ab dieser Kernel-Version unterstützt Rust for Linux mittel- oder langfristig den Rust-Compiler 1.78.0 oder neuer. Doch auch wenn diese Komplikation entfällt: Der Rust-Support behält den Status "Experimentell". Allerlei Distributoren dürften ihn daher weiterhin erst aktivieren, wenn sie auf irgendein Kernel-Feature ausreichend scharf sind, das Rust benötigt.

Grafiktreiber sind die zweite Hürde

Der Code zur Anzeige von QR-Codes bei Kernel-Panics baut auf dem "drm_panic" genannten Feature auf, das Linux seit Version 6.10 bietet und ebenfalls von Jocelyn Falempe stammt. Durch diese kann der Kernel im Fall eines kritischen Fehlers die Grafikausgabe der Desktop-Oberfläche entreißen, um ungestört den Text einer Kernel-Panic anzuzeigen. Zuvor war er dazu nicht in der Lage; sofern denn eine Desktop-Oberfläche lief, fror das Bild zumeist einfach ein, ohne dass der Kernel die Ursache nennen und Informationen zum Debugging ausgeben konnte.

Das Problem: Der verwendete Grafiktreiber muss drm_panic explizit unterstützten. Neben dem generischen Kernel-Treiber Simpledrm beherrschen das derzeit nur einige eher exotische Treiber. Zumindest für den in der x86-Welt gängigen GeForce-Treiber Nouveau hat Falempe schon im Mai Patches zur Unterstützung von drm_panic veröffentlicht, die aber bislang nicht auf dem Weg in den offiziellen Kernel sind. Von entsprechenden Anpassungen für die ebenfalls häufig genutzten Treiber Amdgpu und i915 ist bislang nichts zu sehen, aber Falempe will auch für die sorgen.

Ein drittes Hindernis hat Falempe kürzlich beseitigt: Um drm_panic beim Bau des Kernels aktivieren zu können, müssen Anwender bei Linux 6.11 die Option CONFIG_VT_CONSOLE deaktivieren. Dann zeigt Linux aber beim Start keine Kernel-Meldungen an und kann im Single-User-Modus keinen Notfall-Login autark öffnen. Einige jüngst vorgeschlagene Änderungen eliminieren den Konflikt zwischen den zwei Features; sie fließen nach aktuellem Stand ebenfalls in Linux 6.12 ein, das an den beiden letzten November-Montagen oder dem ersten Montag im Dezember erscheinen sollte.

Ein Webservice zum Dekodieren muss auch jemand betreiben

Für die QR-Code-Panics braucht es darüber hinaus noch einen Webservice, der die im QR-Code enthaltenen Daten per URL erhält und entpackt. Das ist nötig, weil der Kernel die Informationen mit Zlib komprimiert, um alle typischerweise für die Analyse wichtigen Details im QR-Code unterbringen zu können -- darunter die Stelle im Kernel-Code, wo der Fehler auftrat samt eines Backtrace.

Den Quellcode für solch einen Webdienst hat Falempe veröffentlicht. Beim Betreiben solch eines Services entstehen aber natürlich Kosten, die irgendwer abdecken muss. Daher muss man beim Bau eines Kernels mit QR-Code-Panic explizit die URL des zu nutzenden Webdienstes festlegen; dieser fließt dann in den QR-Code ein, damit beliebige Scanner den Weg dorthin autark finden. Es wird sich zeigen müssen, ob jede Distributionen selbst einen solchen Webdienst betreibt oder jemand Vertrauenswürdiges einen für alle zugänglichen einrichtet.

Blue Screens von Systemd lösen anderes Problem

Die "Bluescreen of Death"-Funktion des im vergangenen Dezember veröffentlichten Systemd 255 braucht keinen solchen Dienst, denn dort ist der enthaltene Text normalerweise nicht komprimiert. Dieser Ansatz zielt ohnehin auf andere Fehlersituationen. Eine davon: Beim Booten findet ein im Initramfs (manchmal auch Initrd genannt) enthaltenes Systemd das Volume mit dem Root-Dateisystem nicht. Sofern die Systemkonfiguration dann ein Bereitstellen einer Notfall-Shell zur Handhabung untersagt, gibt es für den System- und Service-Manager dann kein Vor und Zurück mehr.

In solchen Situationen könnte der bei Version 255 eingeführte Dienst "systemd-bsod" dann einen "Blue Screen of Death" mit einer hilfreichen Fehlernachricht anzeigen. Die Alternative wäre aufzugeben und die Verantwortung wieder dem Kernel zu übergeben. Der aber stünde dann vor dem gleichen Dilemma oder einem Folgeproblem. Er würde daher in so einem Fall auch nur mit Fehlern wie "Kernel Panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" oder "Kernel panic - not syncing: Attempted to kill init!" die Flügel strecken.

Linux der Kernel und Linux das Betriebssystem

Szenarien wie dieses gepaart mit dem Namen des Systemd-Dienstes und oberflächlicher Berichterstattung sind der Grund, warum vielerorts der Eindruck entstanden ist, Linux würde jetzt Blue Screens beherrschen. Wenn der Begriff "Linux" nur den sogenannten Kernel meint, ist das falsch; meint er hingegen mit ebendiesem sowie einem aktuellem Systemd gebaute Betriebssysteme, ist das halbwegs korrekt.

Die Unterscheidung ist am Ende aber wichtig: Als Userspace-Programm kann Systemd echte Kernel-Panics gar nicht handhaben, denn bei solchen kommt der Userspace gar nicht mehr zum Zuge; stattdessen gibt der Kernel nur noch einige Informationen zum Debugging aus, um dann den Betrieb bewusst und komplett einzustellen. Das ist im Interesse aller, weil etwa Schadsoftware die Situation sonst womöglich zu ihrem Vorteil nutzen könnte; womöglich ist auch etwas so stark durcheinander geraten, dass Daten oder Hardware Schaden nehmen könnten. Das unterscheidet eine "Kernel Panic" von einem "Kernel Oops". Bei letzterem hat der Kernel auch einen groben Fehler bemerkt, den aber so abgefangen, dass es glaubt, weitgehend korrekt weiterarbeiten zu können. Vollkommen ausgeschlossen sind Folgefehler dann aber auch nicht.

Wahlmöglichkeit: vager Hinweis, Text oder QR-Code

Bei einer Panic reagiert der Kernel aufgrund der Schwere der Situation auch nicht mehr auf Eingaben der Tastatur. Um Nutzern dennoch ein Debugging zu ermöglichen, zeigt er dann viele wahrscheinlich nötige Informationen in einem kompakten Format an – genau wie bei Windows wirkt das eher kryptisch und ist vom Bildschirmplatz beschränkt.

Über komprimierten Text in einem QR-Code ließen sich daher womöglich sogar mehr Informationen transportieren, sofern die Entwickler denn wollen. Aber weil eben der Bildschirmplatz begrenzt ist und der Kernel womöglich nicht mehr auf Eingaben reagiert, müssen Anwender zwischen der klassischen Ausgabe und QR-Code wählen. Das gelingt über Boot-Parameter oder Änderungen an der Datei /sys/module/drm/parameters/panic_screen.

Auf Wunsch können Distributionen die Lösung auch so konfigurieren, dass standardmäßig nur ein vager Hinweis auf einen kritischen Fehler erscheint, der zum Neustart auffordert. Genau das ist derzeit der Plan für das im April 2025 erwartete Fedora Linux 42, das drm_panic nach aktuellen Planungen nutzen soll; eine Triebkraft dahinter ist auch hier wieder Falempe.

Lösungen für ähnliche, aber dennoch unterschiedliche Problemsituationen

Weil sich der Kernel nach Ausgabe der Panic-Informationen komplett verweigert, ist es durchaus sinnvoll, dass auch Systemd in ausweglosen Situationen nähere Details zum Problem per QR-Code ausgeben kann. Denn wenn Systemd diese absehen kann, ist der Kernel noch komplett beisammen. Dadurch kann Systemd-Bsod viel flexibler auf die Situation reagieren und so prinzipiell sogar mit dem Nutzer interagieren. Derzeit unterscheiden sich beiden Lösungen visuell, sodass man diese leicht auseinanderhalten kann; ohnehin können Distributionen bei beiden Ansätzen auch ganz andere Hintergrundfarben als Blau konfigurieren, so sie denn möchten.

(dmk)