Debian Jessie systemd. Why? Oh! Why?!

Alter was?!

Also...

Ich mache da also gestern apt-get dist-upgrade auf meinem Debian/testing Jessie, und bekomme jetzt diesen hochmodernen systemd. Tschuess SysVInit. Tschuess Verstehen, was passiert. Aber das hab ich gestern ja noch gar nicht gemerkt. Der Rechner lief ja noch. Bis ich ihn dann runterfuhr, um ins Bett zu gehen.

Heute dann fahr ich meinen Rechner also wieder hoch. Was begruesst mich?

Welcome to the emergency console. After logging in, use journalctl -xb to see what went wrong (Sinnerhaltend zitiert.) Natuerlich stand das nicht in der letzten Zeile, sondern irgendwo in der Mitte der Schirms inmitten von Matrix-Style-Konsolentext. Natuerlich gabs auch keinen Login, also auch kein 'after logging in'. Danke. Und nun? Jedenfalls irgendwelches Bla von wegen 'systemd', also wusste ich, ok, gestern war wohl der Tag, an dem Debian entschied, Systemd kommt jetzt. Was stand da sonst noch so? Hm. /run/systemd/private nicht gefunden. DBus funktioniert nicht. Ratterratter. Am Schluss haengts irgendwie beim Swap starten. Sehr merkwuerdig alles.

WTF!

Also Reboot. init=/bin/bash. / schreibbar mounten.

emacs /etc/fstab. Kein richtiges TTY. Emacs geht nicht. Fuck You! Nano geht. Swap entfernt.

Reboot. Ich krieg n Login! Auf der Textkonsole. Grr. Hm... Das Update gestern koennte natuerlich auch den Graphiktreiber uebermalt haben. sgfxi soll mir mal n neuen Treiber installieren. Mist. Kein Netz, der Treiber kann nicht gezogen werden. dhclient eth0. Netz! Fast... Namensaufloesung geht natuerlich nicht. Hm. nano /etc/resolv.conf. Komisch. Die Datei ist leer. Hm. nameserver 8.8.8.8 CTRL-O. Speichern? Geht nicht. Die Datei existiere nicht. WTF!

Ja, meine Damen und Herren! Die Datei ist bloss ein Symlink nach /etc/resolvconf/run/resolv.conf Wobei natuerlich, nicht zu vergessen, /etc/resolvconf/run ein Symlink nach /run/resolvconf ist. Soweit, so einfach. Achja. Die Fehlermeldung? Nun: Das Verzeichnis /run/resolvconf existierte nicht. Kein Wunder /run liegt in einem tmpfs und wird bei jedem Boot neu angelegt, bei einem init=/bin/bash ist das nicht gefuellt. Also war der Symlink /etc/resolvconf/run/ -> /run/resolvconf tot, und damit konnte die Datei unter dem Verzeichnis natuerlich nicht gespeichert werden. Klar oder? "File not found"... Das mit den Fehlermeldungen ueber wir nochmal.

m(

Nun hab ich also Netz und kann mir also den Graphiktreiber wieder installieren.

Reboot. Bunt! Kompletter Lockup! Hier half nun leider nur noch der Powerbutton. Hmm... Bloed das. Na, dann wollen wir doch mal einstellen, dass das Bunt halt nicht gestartet wird.
init=/bin/bash .
systemctl disable display-manager
...Could not connect to dbus

Ah. Jetzt kommen wir zu den wirklichen Qualitaeten von Systemd. Man kann das Problem mit dem Booten im Systemd nur dann beheben, wenn der Systemd laeuft! Jaja! Weil Configdateien? Neeeein! Das waere ja zu einfach! Naja. Doch Configdateien. cd /etc/systemd/system ; mv display-manager.service display-manager.service.disabled Super. Das funktioniert. Nun kriege ich nach einem Reboot wieder einen richtigen Textlogin. Das ist doch schonmal ein Zustand, mit dem man arbeiten kann.

Oah ey! Neee!

So. Nun koennen wir uns dem zuwenden, was eigentlich kaputt ist!. Also. Systemd findet immer diese /run/systemd/private nicht, das ist ein Socket, und darueber geht irgendwie die systemd-interne Kommunikation und die Kommunikation mit den Interface-Tools. Hm. Gut. Schaun wir mal. Vielleicht kriegen wir ja Hinweise. journalctl -xb Das soll ja, wie mir Systemd schon selbst erzaehlt hat, da mal Logs zeigen.

/run/systemd/private not found.

Ah. Cool. journalctl funktioniert nur, wenn Systemd laeuft. D.h. wenn Systemd abschmiert hab ich keinerlei Moeglichkeit zu sehen, was eigentlich los ist. In /var/log findet sich jedenfalls nix. Auch nicht, nachdem ich in /etc/systemd/system.conf: Logging=persistent reinschreibe. Fuck You!

Na gehen wir mal forschen. Also in /run gibts nicht mal ein /run/systemd. komisch. Hmhm. Google. Hm. Sollte es aber. Hm. Auf einen Hunch hin, geb ich mount ein. Was sehen meine mueden und genervten Augen? /run ist 2x gemountet.

umount /run. Geht nicht. In Use.
umount -l /run. ok... Whoa. journalctl -xb liefert ein Log. Ich werd nicht mehr! Den Kommunikationssocket gabs doch. Er war nur verdeckt von einem ueberfluessigen Mount. Hah! Dann werden wir das ja mal ganz leicht los! Wo kommt der 2. Mount denn her? Hm... in /etc/fstab wird /run nicht gemountet. Aehm. Ja. Fragen wir journalctl. Ich komm zwar mit den bloeden Optionen noch nicht so klar, aber was ich finde ist nix mit /run, sondern mit /var/run. Genauer var-run.mount. Irgendwie ist das nicht das gleiche, aber ich hab das Bauchgefuehl, dass ich dem nachgehen sollte. var-run.mount also. Das ist so n Systemd-Ding. So ein Mount-Target-Unit-Dings. Systemd hat so Dateien, die auf .service und .mount enden, und da definiert man dann seine Services und Mountpoints. Weil /etc/fstab ist ja aus der Mode.
Die var-run.mount existiert nur nicht. find, locate, updatedb, locate. Nein. Sie existiert nicht. Vielleicht ist dieses Target-Mount-Dings nur ein Eintrag in einer Datei die anders heisst? Hm... Greppen wir mal.

Die Ironie!

/lib/systemd/system# rgrep var-run.mount *
grep: Ungültige Option -- .

Ok. Was?! Nachdem ich nun also langsam anfange, meine Model-M kaputt zu schlagen, merke ich, dass Systemd so schlau ist, in dem Verzeichnis eine Datei namens -.slice aufzubewahren. Und alle Tools, ls, grep, rgrep, etc nehmen hier an, ein Switch kaeme nach dem Minus, und aber einen Switch -. gibts nicht. Abbruch.

Also:
/lib/systemd/system# rgrep var-run.mount -- *
debian-fixup.service:Before=var-run.mount var-lock.mount sysinit.target

Dies hier ist tatsaechlich das einzige Vorkommen im Systemd, welches ich gefunden habe. Dies ist allerdings nicht die Definition, sondern eine Referenz. Nicht das, was ich suche. Die Ironie? Die Datei in dem das vorkommt, sollte ein Problem mit Debian und Systemd fixen!

Endgame

Nun suche ich also noch ne Weile wild und willkuerlich herum, und weiss langsam nicht mehr wirklich, was denn nun. Aber Logs sind doch das, was am Ende hilft. journalctl und ein suchen nach var-run.mount liefert mir den Hinweis, dass es sich bei var-run.mount nicht um eine Datei handelt (dabei gibts einige .mount-Dateien!), sondern um eine quasi virtuelle Datei, die die Zeile /var/run in der /etc/fstab beschreibt. Und da /var/run ja in der Transition nach /run zu einem Symlink wurde, wurde ein Mount nach /var/run zu einem Mount nach /run, welcher dann den Systemd-Kommunikationssocket ueberdeckt hat.

Rausmachen.

Geht.

Ich hasse euch alle fuer eure Windosen und Apples, die einfach so gehen! </sarkasmus>