Vor drei Jahren habe ich einen Artikel geschrieben, in dem erklärt wurde, wie man nach einem fehlgeschlagenen Start nach einem größeren Versions-Upgrade in Fedora wiederherstellt. Ich arbeitete damals mit Fedora 25 und kam plötzlich nicht mehr auf den Desktop. Das Problem stellte sich als fehlerhaftes initramfs heraus, was ein Problem ist, auf das ich in der Vergangenheit nur einmal gestoßen bin, damals in Ubuntu, damals im Jahr 2009. Seitdem ist es ruhig.
Nun, das Rad der Zeit hat uns an den Anfang zurückgeworfen. Das gleiche Problem trat erneut auf. Ich hatte (etwas) kürzlich eine Instanz von Fedora 29 auf Fedora 30 aktualisiert, und siehe da, ich stand vor dem gleichen Problem. Fast. Ich hatte einen schwarzen Bildschirm und eine Meldung, die besagte:Der Zugriff auf die Konsole kann nicht geöffnet werden, das Root-Konto ist gesperrt. Zu diesem Zeitpunkt brachte der Versuch, irgendetwas zu tun, keine Ergebnisse. Ich konnte nur neu starten. Ich habe einen anderen Kernel ausprobiert, und das hat geholfen - ich bin auf meinen Desktop gekommen. Obwohl das Problem ähnlich zu sein scheint, musste ich einen etwas anderen Weg gehen, um es zu beheben.
Problemsymptome im Detail
Ich war ziemlich verblüfft über das Fehlen zugänglicher Diagnosetools oder einer brauchbaren Umgebung, in der ich das Problem beheben konnte. Einen Neustart durchführen zu müssen bedeutet, möglicherweise wertvolle Informationen zu verlieren. Zumindest konnte ich in andere Kernel booten, was bedeutete, dass ich etwas hatte, womit ich arbeiten konnte.
Im neuesten Kernel-1 habe ich zuerst versucht, meinen eigenen Rat von vor zwei Jahren zu befolgen, aber der Befehl systemctl status boot-efi.mount zeigte nichts Brauchbares. Ich bin immer wieder verblüfft darüber, wie zerbrechlich, komplex und nicht wirklich menschenfreundlich das neue und moderne Boot-Framework ist. Die vorherige Ausgabe veranlasste mich, meinen Artikel Fortschritt durch Komplexität zu schreiben, und seine Schlussfolgerungen sind Jahre später immer noch gültig.
Das einfachste Hindernis ist die Verfügbarkeit von Informationen unter /var/log. In den guten alten Init-Tagen fanden Sie dort normalerweise Folgendes:syslog/messages, boot, old boot und kernel logs. Dies waren Textdateien, die Sie einfach und sofort mit cat, less, what., inspizieren konnten.
In Fedora erhalten Sie einige, aber nicht alle dieser Dateien. Zum Beispiel ist boot.log da, aber dann:
sudo less boot.log
"boot.log" kann eine Binärdatei sein. Sehen Sie es trotzdem?
Lustigerweise IST es eine Textdatei (mit einigen seltsamen Zeichen), und Sie können sie tatsächlich mit cat anzeigen. Aber diese Datei lieferte keine nützlichen Informationen, die mir helfen würden, das Problem zu lokalisieren.
Ich habe dann etwas mehr Zeit damit verbracht, verschiedene Optionen für journalctl zu lesen, und es gibt Ihnen die Möglichkeit, die vorherigen Boot-Protokolle anzuzeigen. Sie können dies tun, indem Sie einen negativen ganzzahligen Wert angeben, um die alten Protokolle anzuzeigen. Das ist nicht sehr intuitiv, aber zumindest hat es mir das gegeben, was ich brauchte, obwohl ich die Idee des binären Log-Formats im Prinzip ablehne. Sie haben dies kürzlich gesehen, als ich das Problem mit dem geborstenen Laptop debuggte. Ähnliches Thema.
journalctl --boot=-1
Hier bin ich die Zeilen durchgegangen und habe nach Fehlern gesucht. Während das Systemctl-Ding früher nicht geholfen hat, bin ich mit diesem Befehl schließlich auf das kritische Boot-Problem gestoßen:
11. Juli 13:55:07 Tester systemd[1]:Mounten /boot/efi...
11. Juli 13:55:07 Tester mount[899]:Mount:/boot/efi:Unbekannter Dateisystemtyp 'vfat '.
11. Juli 13:55:07 Tester systemd[1]:boot-efi.mount:Mount-Prozess beendet, Code=beendet, Status=32/n/a
11. Juli 13:55:07 Tester systemd[1]:boot-efi.mount:Fehler mit Ergebnis „exit-code“.
11. Juli 13:55:07 Tester systemd[1]:Mounten von /boot/efi fehlgeschlagen.
11. Juli 13:55:07 Tester systemd[1]:Abhängigkeit für lokale Dateisysteme fehlgeschlagen.
11. Juli 13:55:07 Tester systemd[1]:local-fs.target:Job local-fs.target/start ist mit dem Ergebnis 'dependency' fehlgeschlagen.
11. Juli 13:55:07 Tester systemd[1]:local-fs.target:Triggering OnFailure=dependencies.
Ganz ähnlich wie vor drei Jahren. Wir scheinen also wieder ein schlecht zusammengestelltes Initramfs zu haben, was für meinen Geschmack viel zu oft vorkommt. Außerdem ist es mit dem Versions-Upgrade korreliert. Ich frage mich, was an dem FAT32-Modul so schwierig sein kann, aber das ist eine Frage für jemand anderen. Was die initramfs-Dateien betrifft, hatte ich unter /boot Folgendes:
ls -ltr initramfs*
-rw-------. 1 root root 73443963 19. Mai 2018 initramfs-0-rescue-efe3eec4bb6646fe864735812f4d094b.img
-rw-------. 1 root root 22953495 Apr 2 15:54 initramfs-5.0.4-200.fc29.x86_64.img
-rw-------. 1 root root 22961687 20. Mai 13:11 initramfs-5.0.16-200.fc29.x86_64.img
-rw-------. 1 root root 23015208 20. Mai 21:17 initramfs-5.0.16-300.fc30.x86_64.img
Der letzte war der Übeltäter, während der vorherige (oben) gut funktionierte. Was auch immer während des Updates passiert ist, hat das zweite initramfs beschädigt, ohne dass das vfat-Modul das korrekte Mounten des Dateisystems ermöglicht. Aus Neugier entschied ich mich, die Bilder zu extrahieren, um die Unterschiede zu sehen – was meinen Verdacht bestätigte. Auch dies war nicht die trivialste Übung, da Sie zcat und cpio nicht wie in der Vergangenheit zum Extrahieren der initarmfs-Dateien verwenden können, sondern eine komplexere Kombination benötigen:
/usr/lib/dracut/skipcpio initramfs-"Version".img | zkat | cpio -id
Lösung
Nun, Sie haben hier mehrere Möglichkeiten. Erstens, wenn Sie eine zweite Kopie von Fedora auf derselben Box haben und es funktioniert, dann können Sie die initramfs-Datei kopieren und verwenden, wie ich es damals in Ubuntu getan habe. Dies ist keine triviale Option, aber wenn Sie sie haben, haben Sie Glück!
Wenn Sie dies nicht tun, sollten ältere Kernel helfen - wie sie es in meinem Szenario getan haben. Anschließend können Sie ein Systemupdate ausführen oder initramfs-Dateien manuell neu erstellen. Sie können meinen Ubuntu-Artikel zum langsamen Booten lesen, um Einzelheiten dazu zu erfahren. Wenn Sie in keinen anderen Kernel booten können und keine anderen Linux-Instanzen auf dem Host haben, dann ist Ihre letzte Option, die Live-Sitzung zu verwenden und dann dort die Wiederherstellung durchzuführen - oder neu zu installieren.
Schlussfolgerung
Ich bin überrascht und etwas bestürzt über diese Situation - alles davon. Der Fehler selbst, die Unfähigkeit, live zu debuggen, die Tatsache, dass mir dies nach einem Fedora-Upgrade (wieder) passiert ist, die Tatsache, dass ich nach normalen Systemaktivitäten mit einer nicht bootfähigen Distribution endete, die Gesamtkomplexität von systemd. All dies hinterlässt bei mir ein Gefühl des Unbehagens.
Im Jahr 2020 ist die Welt der Technik nicht abstrakter, robuster oder widerstandsfähiger als vor zehn Jahren. Im Gegenteil, Fehler passieren immer wieder, und wenn sie zum Tragen kommen, ist das umgebende Ökosystem viel schwieriger zu bedienen und zu bearbeiten als in der Vergangenheit. Dies macht die Fehlerbehebung und Problemlösung frustrierender. Also ja, ich habe es repariert, und vielleicht zählt das, aber nein, das zählt nicht. Eine nahtlose Benutzererfahrung ist das Endziel. Leider driftet der Linux-Desktop Tag für Tag langsam weiter von dieser edlen Mission ab und wird im Gesamtplan der Dinge immer irrelevanter. Wie auch immer, auf der technischen Seite hoffe ich, dass dieser Artikel nützlich war. Pass auf dich auf.