Leserartikel Wenn Linux blau sieht: Ein Windows-Klassiker auf Abwegen

kim88

Lt. Commander
Registriert
Sep. 2016
Beiträge
1.851
Mit systemd in Version 255, das wahrscheinlich irgendwann im Dezember 2023 veröffentlicht wird, kommt nun zum ersten Mal der unter Windows bekannte «Bluescreen» zu Linux.

Nachfolgend schreibe ich etwas zur Geschichte des Bluescreens, warum Microsoft ihn entwickelt hat und warum das auch für Linux eine gute Idee ist.

Warum ist der Bluescreen blau?​

Der erste Bluescreen gab es mit Windows NT 3.1 aus dem Jahr 1993 und wurde in den nachfolgenden Jahren in allen Windows-Versionen integriert. Entwickelt wurde der Bluescreen vom damaligen Microsoft-Mitarbeiter John Vert.


Windows_NT_3.51_BSOD.png

Windows NT 3.1 Bluescreen

Er programmierte am liebsten mit dem Texteditor «Slickedit», der damals einen blauen Hintergrund mit weisser Schrift hatte. Da auch die Firmware seines Rechners damals weisse Schrift auf blauem Hintergrund nutzte, liess er sich davon inspirieren und gestaltete das Programm mit blauem Hintergrund und weisser Schrift.

Warum gibt es einen Bluescreen?​

Der Bluescreen ist ein Diagnosewerkzeug für Systemadministratoren. Sobald das Betriebssystem einen Fehler feststellt, wird das System zum Schutz vor Schäden an Dateien angehalten, und der Bluescreen erscheint.

Der Bluescreen zeigt dann einen Fehlercode an, der einem Systemadministrator helfen soll, das Problem zu identifizieren und lösen zu können.

Zusätzlich legt er einen «Memory Dump» an, das heisst, der komplette Inhalt des Arbeitsspeichers wird auf die Festplatte kopiert, was bei der Fehlersuche hilft.

Die häufigste Ursache für einen Bluescreen unter Windows sind Treiberprobleme, z. B. veraltete Treiber, die mit dem aktuellen Windows nicht mehr kompatibel sind und so zu einem Fehler führen. Oft können aber auch Hardwaredefekte einen Bluescreen auslösen.

Insgesamt ist der Bluescreen ein wichtiges Diagnosewerkzeug, das bei der Fehlersuche und -behebung in Windows-Betriebssystemen hilft. Trotz seines oft negativen Rufs, da er mit Systemabstürzen verbunden ist, spielt er eine wichtige Rolle bei der Aufrechterhaltung der Systemstabilität und -sicherheit bei Windows.

Wie funktioniert das eigentlich unter Linux?​

Wie wir wissen, ist Linux nicht Windows, und Dinge funktionieren oft unterschiedlich. Systemabstürze und fehlerhafte Treiber (Hallo Nvidia 🙄) kann es definitiv auch unter Linux geben. Hier kennen wir das Phänomen als «Kernel Panic».


kernel_panic_redhat.jpg

Beispiel einer Linux Kernel Panic unter Red Hat Linux

Das Problem an der Kernel Panic ist, dass die Meldungen nicht sehr benutzerfreundlich sind. Wenn man kein Kernel-Entwickler ist, kann man mit den Fehlermeldungen wenig anfangen. Für Normalsterbliche gibt die Fehlermeldung keine Anhaltspunkte.

Wie kam es nun zum Bluescreen bei Linux?​

In einem «Feature Request» wurde von systemd gefordert, eine Möglichkeit zu schaffen, dass bei einem Boot-Fehler von Linux eine Vollbild-Fehlermeldung mit einem für Menschen verständlichen Fehlername angezeigt wird. Zusätzlich soll es die Möglichkeit geben, dass Linux-Distributionen dort einen QR-Code einbinden können, der auf ihre eigenen Hilfeseiten führt und somit den Nutzern die Möglichkeit gibt, Anleitungen zu finden, wie sie das Problem beheben können.

Und das ist die Geburtsstunde von «systemd-bsod.service». Der Name «bsod» ist übrigens eine liebe Hommage an Microsoft. Im englischen Sprachraum hat sich der Name «Blue Screen of Death» etabliert. Und genau dafür steht die Abkürzung «bsod».


systemd-bsod.jpeg

So wird der Bluescreen unter Linux etwa aussehen: Er ist von der Idee und dem Layout sehr an den Bluescreen von Windows 10 angelehnt.

windows10-bsod.jpg

Als Vergleich der Bluescreen bei Windows 10


Ob und wann Ihre Distribution den Service einbindet, kann ich Ihnen leider nicht sagen. Systemd ist extrem modular aufgebaut, das bedeutet, Linux-Distributionen müssen den Service nicht übernehmen. Was man mit Sicherheit sagen kann, ist, dass eine zukünftige Red Hat-Version den Service wohl mitbringen wird – weil das Anliegen von Red Hat gepusht wurde.

Fazit: Ein neues Kapitel in der Linux-Geschichte – jetzt auch in Blau!​

Man könnte sagen, dass Linux mit dem neuen systemd-bsod.service ein wenig Farbe in sein Leben bringt – und diese Farbe ist ausgerechnet Blau! Es ist, als würde Linux beschliessen, dass es Zeit für eine kleine Mode-Revolution ist. Stellen Sie sich vor, Linux, das bisher eher im Hintergrund gearbeitet hat, zieht nun plötzlich eine knallblaue Jacke an und sagt: «Hey, auch ich kann auffallen!»

Aber keine Sorge, dieser stilistische Wandel ist mehr als nur ein optisches Update. Es ist, als würde Linux sagen: «Ich habe euch verstanden – Fehlermeldungen sollen nicht nur für Computer-Gurus verständlich sein.» Mit klaren, benutzerfreundlichen Informationen und hilfreichen QR-Codes wird der Bluescreen unter Linux zu einem echten Helfer in der Not.

Und denkt nur an die Ironie – jahrelang war der Bluescreen das Symbol für Windows-Ärger, und jetzt wird er von Linux in einem neuen Licht präsentiert. Es ist, als würde ein alter Klassiker eine moderne Neuaufführung erleben. Ganz nach dem Motto: Alte Ideen, neu interpretiert.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Avero, oelmiene, Gamienator und 24 andere
Dave's Garage Kanal ist eine Empfehlung ...

 
  • Gefällt mir
Reaktionen: oelmiene und kim88
Coole Sache!

Ich habe zwar noch keine Kernel Panic erlebt, aber das Feature ist gut! :)
 
  • Gefällt mir
Reaktionen: klausk1978
@oicfar Der Kanal ist definitiv eine Empfehlung - dieses Video nutzte ich in der Recherche auch als Quelle :)
 
  • Gefällt mir
Reaktionen: oicfar
kim88 schrieb:
In einem «Feature Request» wurde von systemd gefordert, eine Möglichkeit zu schaffen, dass bei einem Boot-Fehler von Linux eine Vollbild-Fehlermeldung mit einem für Menschen verständlichen Fehlername angezeigt wird.
Du schreibst hier von einem Boot Fehler. Betrifft das wirklich nur Boot Vorgänge? Kernel Panics können ja auch im laufenden Betrieb auftreten.

Und besteht für Systemintegratoren die Möglichkeit, den Inhalt der Fehlermeldungen und QR Codes zu beeinflussen? Ich stelle mir ein grafisches Bedienterminal mit embedded Linux vor, z.B. in der Industrieautomatisierung, auf dem plötzlich der Wifi Treiber abschmiert. Da wäre es hilfreich, wenn der Benutzer nicht zu allgemeinen Systemd Seiten, sondern zum Hersteller des Terminals geführt wird. Der kann im Zweifel eher helfen.

Ansonsten: Top Beitrag!
 
@riversource Naja es ist openSource alle können alles Beeinflussen. Daher wenn man ein Embedsystem baut und systemd-bsod.service verwendet kann man das so anpassen wie man es haben möchte.

Out-of-the-Box in der ersten Version ist nur vorgesehen, dass die Distirbutoren die QR Codes bzw die dabei hinterlegten Links anpassen können - und somit auf ihre eigene Dokumentationen verweisen können.

Und - zumindest auch hier in der ersten Version - rennt das Ding nur beim Systemboot. Aber ich denke es wird sicherlich noch ausgebaut werden.
 
  • Gefällt mir
Reaktionen: riversource
Man merkt, dass Poettering für Microsoft arbeitet :D
Spaß beiseite, das dürfte bei Kernel-Panics durchaus nützlich sein. Hoffentlich kann ich das nicht zu bald testen.
 
Auch wenn sich die Witze da ganz von alleine schreiben, ist sowas objektiv gesehen OK, solange es optional ist. Ein sinnvolles Feature für "einsteigerfreundliche" Distris, die die User nicht mit zu kryptischen technischen Details überfordern wollen.
 
  • Gefällt mir
Reaktionen: kim88
Jeder weiß doch, dass der BSoD (Bastard Sysadmin of Doom) der Kollege vom BAfH ist 🤣
 
  • Gefällt mir
Reaktionen: LinuxTux und knoxxi
kim88 schrieb:
Ob und wann Ihre Distribution den Service einbindet, kann ich Ihnen leider nicht sagen. Systemd ist extrem modular aufgebaut, das bedeutet, Linux-Distributionen müssen den Service nicht übernehmen. Was man mit Sicherheit sagen kann, ist, dass eine zukünftige Red Hat-Version den Service wohl mitbringen wird – weil das Anliegen von Red Hat gepusht wurde.
Naja, wenn man Cases auf der Ebene mit Redhat hat ist es extrem vorteilhaft wenn man eine "richtige" serielle Console hat bei der man die Daten als ascii in das Case-Tool von Redhat rein werfen kann anstatt irgendwelcher Screenshots die im Extremfall noch über mehrere Seiten gehen. Besser wäre natürlich eine dedizierte HW wo man Daten über einen Reboot speichern kann damit das OS beim nächsten diese Daten ins Filesystem kopieren kann. Nichts ist nerviger als Kisten die sich spontan auf die Bretter legen und man hinterher keine vernünftigen Infos zu den Crash hat, und der Crash aus dem Grund foo oder bar nicht funktioniert hat. So hätte man wenigstens noch die Daten die bei einem Crash auf der Console stehen. Und nein, im Service Prozessor (ILO, IDRAC, LOM, etc.) stehen keine Daten vom OS.

Und die Daten von einem Crashdump liegen hinterher sowieso im Filesystem, ob der Bildschirm grün, rosa oder blau ist während der Crashdump geschrieben wird juckt keine Sau.

Und wer beim booten Probleme hat sollte auch besser diesen albernen Splashscreen abschalten.
"nosplash" in der KernelCmdLine bzw. Grub.

Und QR-Codes sind auch beschränkt bzgl. der Anzahl vom Daten die man damit darstellen kann.

Fazit: Kinderkacke.
 
Zuletzt bearbeitet:
kim88 schrieb:
So wird die Bluescreen unter Linux aussehenAls Vergleich der Bluescreen bei Windows 10
Da unter dem Windows Bild ist etwas zu viel Text. Das "So wird die Bluescreen unter Linux aussehen" ist vermutlich zu viel.
 
  • Gefällt mir
Reaktionen: kim88
Ist bekannt, ob der Service irgendwelche Abhängigkeiten hat oder kann man den auch einfach deaktivieren, wenn man diese Funktionalität nicht benötigt/haben will?
 
Soweit mir bekannt kann man ihn einfach deaktivieren. Wahrscheinlich auch deinstallieren, da er wohl bei den meisten Distributionen die ihn einbauen werden ein eigenes Paket sein wird.
 
  • Gefällt mir
Reaktionen: Tanzmusikus und Capet
kim88 schrieb:
Zusätzlich legt er einen «Memory Dump» an, das heisst, der komplette Inhalt des Arbeitsspeichers wird auf die Festplatte kopiert, was bei der Fehlersuche hilft.
Du sagst ja richtigerweise, das der Bluescreen zum Schutz von Daten usw. ausgelöst wird, damit nicht mehr kaputt geht. Die spannende Frage ist ja: Wie kriegt man dann den Memory-Dump auf die Platte. Einfach normal mit dem Filesystem interagieren geht ja nicht, weil man davon ausgehen muss, das das System so kaputt ist, das es das nicht mehr sauber geschrieben werden kann.

kim88 schrieb:
Systemd ist extrem modular aufgebaut
Naja. Extrem modular ist übertrieben. Erstens ist es ja keine Modularität in der Weise, das man Komponenten frei zusammenstecken kann wie man will. Es ist eher so, das man ein Grundsystem hat und dazu halt Plugins angeboten werden.
Zum anderen ist der Core immer noch relativ groß.

Ich möchte das an dieser Stelle auch gar nicht kritisieren. Ich finde nur die Formulierung "extrem modular" ist das ein bisschen drüber.
 
kim88 schrieb:
Der Kanal ist definitiv eine Empfehlung
Wenn der Titel schon clickbaitmäßig und falsch ist? Der Ursprung vom Bluescreen ist vielleicht den meisten nicht geläufig, aber deswegen noch lange kein "Geheimnis"?
 
@daivdon YouTube funktioniert dadurch das man Klicks generiert. Clickbait Titel funktionieren deswegen macht man sie. Der Kanal ist dennoch eine Epfehlung.
 
daivdon schrieb:
Wenn der Titel schon clickbaitmäßig und falsch ist? Der Ursprung vom Bluescreen ist vielleicht den meisten nicht geläufig, aber deswegen noch lange kein "Geheimnis"?
@daivdon clickbaitmäßig? Der Kanal ist von einem EX-Microsoft Mitarbeiter. Was hat das mit clickbaitmäßig zu tun? Erst lesen, gucken und dann kommentieren. Wenn du den Kanal nicht kennst, dann solltest du dir mal anschauen. Hat sehr viele interessante Inhalte.
 
andy_m4 schrieb:
Du sagst ja richtigerweise, das der Bluescreen zum Schutz von Daten usw. ausgelöst wird, damit nicht mehr kaputt geht. Die spannende Frage ist ja: Wie kriegt man dann den Memory-Dump auf die Platte. Einfach normal mit dem Filesystem interagieren geht ja nicht, weil man davon ausgehen muss, das das System so kaputt ist, das es das nicht mehr sauber geschrieben werden kann.
Via kexec wird ein crashdump-kernel gestartet der nicht das RAM überschreibt, dieser kernel startet dann ein tool um den RAM und die Register an einen Ort zu sichern den man vorher konfiguriert hat.
Zusätzlich können bestimmte sysctls gesetzt werden um bei non-fatalen Problemen crashs auszulösen:
https://docs.oracle.com/en/operating-systems/oracle-linux/6/admin/ol_panic_params.html

https://www.kernel.org/doc/Documentation/kdump/kdump.txt
https://de.wikipedia.org/wiki/Kdump



Kdump.svg.png
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: klausk1978, andy_m4 und Tanzmusikus
Zurück
Oben