Kleines Follow-Up auf Warnung: Libreswan kann Ihren Bootprozess stören. Nachdem der Rechner gestern wieder lief, wie man im Beitrag auch nachlesen kann, dachte ich mir, probier das System mal mit allen wichtigen Sachen aus. Keine Fehler, die nicht zu erwarten gewesen wären. Mehrfaches Rebooten lief auch ohne Probleme durch, bis… ja, bis heute morgen.
„Der Morgen danach“ Ein Roman von B.Soffski
Der Reihe nach: Wir verließen unseren Helden, als er sich zur Nachtruhe zurückzog und den Rechner ausschaltete. Ja, ausschaltete. Die Art von Ausschalten, die Veränderungen an so einem Computer unmöglich macht. Die Art, wo das Wort stromlos drin vorkommt. Wir erinnern uns, daß der Computer vor diesem Ausschalten 3x neu gestartet wurde, nur um zu sehen, ob das mit dem Reboot auch wirklich klappt.
„Der Vormittag kam, sah und ihm klappten alle Regentropfen runter!“
Anders ausgedrückt, dieses Fedora 29 bootet schon wieder nicht. Es blieb „wieder“ beim NetworkManagereinsatz hängen 🙁 Das kann einfach nicht wahr sein, der hat doch gestern 3x neu gebootet, wie kann das sein?
„Karma is a Bitch“ ein Buch von L.Eben
Na gut. „Challenge accepted“ Eine gewisse Wut im Bauch ist ja nicht wirklich falsch bei so was, es spornt den Wüterich zu Leistungen an. Was machen? Das gleiche wie Gestern? Einen Versuch ist es wert, aber diesmal nicht in eine Rootshell booten, sondern in Runlevel 1 auch bekannt als Emergency.target von Systemd. Ja, also an sich eine gute Idee, NUR GEHTS NICHT! Was für eine verf******* S******* ist das denn?
Ok, also dem Kernel wieder erzählt „1 init=/bin/bash“, Netzwerk gestartet, dnf update und siehe, wieder ein Update. Aber total irrelevant. Das wars also nicht. /var/log/messages und systemd-journal gesichtet, nichts. Der Bootvorgang ging bis NetworkManager, aber das wars dann. Nicht mal mehr ein Crash, der etwas erklären könnte. Nada!
Auf Verdacht wurde dann „dnf reinstall NetworkManager* systemd*“ durchgeführt und “ systemd.debug-level=1 “ an die Kernelzeile angefügt, damit eine Rootshell bereitsteht, wenn man sie braucht ( ALT+F9 ) und was soll ich sagen, der Rechner bootete wieder in GDM. Was fürn Sch….. was ist das denn? Man kann nicht mehr in den Desktop einloggen ?!?!?! Root-Konsole mit ALT+F3 ( F9 hatte ich im Moment vergessen ), will mit Root einloggen und … sofortiger Logout. Und dann stehst Du da!
F9! Stimmt, einloggen nicht nötig, bin ja schon drin, also ab ins Logfile und ..
The Execution of /usr/lib/systemd/systemd resulted in „Permission denied!“
Äh.. den habe ich doch gerade erst frisch reinstalliert und wieso wird der beim Konsolenlogin aufgerufen?Wird er gar nicht, weil /bin/sh konnte man auch nicht mehr starten, gleicher Fehler „Permission denied!“ … und wenn Du jetzt F*** sagst, sag auch gleich SELINUX! NNNNNNEEEEEEEIIIIIINNNNNNNNNNNN!!!!!!!!!!!!! Nicht schon wieder SELinux! Ich fange an es zu hassen !
Einen Reboot mit dem Kernelparameter „enforcing=0“ später, fährt das System hoch, als wenn nie was gewesen wäre!
Aber was ist jetzt schon wieder mit SELinux und wieso hat das System denn überhaupt nach dem Upgrade gestartet? Das dürfte es doch gar nicht. Antwort: SELinux ist halt auch nur eine von Menschen gemachte Software 😉
„Die Auflösung“ Ein Film von D.Itrich
Das Problem nahm seinen Lauf im Jahre 2018. Damals gab es ein Problem unter F27 mit den SEL Policies. Nach einem Update der SEL Policypacks startete das System nicht mehr, aber mit der Version davon lief es noch. Also trägt der Linuxer natürlich nach dem Downgrade den Updateinhibiter für das Paket ein und weil alles ein Jahr lang läuft, vergißt man es. Dann kommt das Systemupgrade auf F28 und es läuft auch mit der alten Policy, was blöd ist, weil man so beim Update auf F29 gar nicht mehr an diese Sperre denkt 🙂
Update sperre für die Pakete raus und „dnf update -y“ ausgeführt. Eine Ewigkeit später, weil gleich mal umgelabelt wird, dann die Probe: reboot ! Scheiße, geht!
Ob die Geschichte diesmal zu ende ist, oder ob morgen neuer Ärger auf mich wartet, könnt Ihr leider erst morgen lesen 😉