Ich sags euch. Die Hölle. Und nicht nur einmal. Mehrmals. Equivalent zur Anzahl an zu aktualisierenden Debian-Installationen.

Nachdem ich es an einem Sonntag Abend für eine gute Idee hielt einen vServer (OpenVZ-virtualisiert, 512 MB RAM, 50 GB HDD, Debian Wheezy) zu aktualisieren, kam mir das Grauen. Ein Chef von mir hat die Devise “Am Freitag nichts wichtiges machen.” – grundsätzlich trifft diese auf das ganze Wochenende zu. Vorallem bei einem hohen Grad an Müdigkeit.

Was genau ist passiert? Nach dem grundsätzlichen Verfahren das Internet und die Änderungen in Jessie zu konsultieren der Änderung aller “wheezy” Vorkommnisse in der /etc/apt/sources.list (der Server war weitgehend mit Standardpaketen aus dem Debian-Repo gefüllt) wurde ein simples apt-get update && apt-get dist-upgrade durchgeführt. Das ratterte schön vor sich hin, fragte hin und wieder zwecks der Installation von neuen Konfigurationsdateien die ich nach einem kurzen Diff-Check bejahte und war schließlich fertig. Da ich ungerne Unsicherheit habe was den irgendwann doch mal nötigen Systemneustart betrifft, führte ich diesen prompt aus.

Allerdings war schon da irgendwas nicht mehr ganz koscher. Der shutdown-Befehl als auch der nicht forcierte reboot-Befehl funktionierte nicht mehr. Letztlich startete ich den Container über SolusVM neu. “reboot -f” hätte es vermutlich auch getan, aber da kam ich nicht gleich drauf.
Nach dem sehr holprigen Neustart offenbarte sich mir ein System mit dem ich nicht gerechnet hatte. Es liefen genau 4 Prozesse. Sonst nichts. dbus und Co. funktionierten nicht. Selbst die Netzwerkverbindungen funktionierten nicht – ich bediente den Container über die serielle Konsole.

Und jetzt versetzt euch bitte in folgende Situation: Ihr hattet einen anstrengenden Tag, es ist sehr spät, ihr müsst morgen früh raus und das VPS auf dem etwas mittelwichtiges (diese Seite) liegt, funktioniert nicht mehr. Mit Symptomen, die sich nicht einfach mal durch 5 Minuten googel und copy&paste beheben lassen.
Jetzt werden einige sagen “Ja aber sicher hattest du ein Backup.” … und natürlich hatte ich ein Backup. Ich habe unzählige Backups. Aber so ein Backup einzuspielen, auch Desasterrecovery kostet eine Menge Zeit.

Also wollte ich gerne einen anderen Ansatz nehmen und den Container reparieren. So, dass alles schön wie vorher war. Meine Überlegung war nun folgende:

F: Welche großen Änderungen wurden im Vergleich zu vorher durchgeführt?
A: Einführung von systemd.

F: Wie werde ich systemd (vorübergehend, versteht mich nicht falsch, ich bin kein Verweigerer des Fortschritts) los?
A: sysvinit installieren.

F: Wie ein Paket installieren, ohne das eine Internetverbindung besteht?
A: Internetverbindung herstellen.

So, und nun der Reihe nach.

Wir stellen fest:

• shutdown geht nicht mehr wegen kaputtem init
• Start von Scripten unter /etc/init.d/ geht nicht mehr wegen kaputtem init
• Daemons (die meisten) starten nicht mehr wegen nicht laufendem dbus
• Das Networking funktioniert wegen Punkt 2 nicht

Was tun?

• dbus manuell starten
• Netzwerkverbindung manuell starten

dbus manuell starten

/sbin/dbus-daemon –session

Die einfachere Übung. Um weiter in der Konsole hantieren zu können, am besten gleich eine zweite aufmachen. “screen” dürfte wegen init auch nicht gehen.

Netzwerkverbindung manuell starten

ifup venet0
ifup venet0:0

Im Idealfall kennen die beiden Interfaces ihre IP, Netzmaske und das Gateway bereits. Ansonsten gilt es, mittels

ifconfig venet0 add 192.168.1.123

dem Interface die richtige IP zuzuordnen.

Ist das getan, kann es notwendig sein, die Routen einzustellen. Funktionieren diese nicht, merkt man das meist an einer nicht funktionieren den Verbindung und daran, dass das Interface zwar bereits einige wenige Pakete gesendet, aber noch 0 empfangen hat. Die Routen kann man wie folgt setzen:

route add default dev venet0

sysvinit installieren (Quelle)

Da die Internetverbindung nun steht und dbus läuft, installieren wir sysvinit:

apt-get install sysvinit-core sysvinit sysvinit-utils

In der Quelle finden sich noch einige weitere Tipps, die ich aber für eine grundlegende Funktionalität nicht als nötig erachtete.

Anschließend ein Reboot, diesmal gleich mittels

reboot -f

Und alles sollte wieder beim alten sein.

Fazit

An dieser Stelle sei angemerkt, dass ich den Container später ausgeschlafen und ohne Zeitdruck komplett neu (mit systemd und Jessie) installieren werde. Auf einem anderen “frischen” Container hat das bereits funktioniert. Sprich, da es noch kein Jessie-Image beim ISP gibt: sauberes Debian Wheezy minimal installiert -> Quellen geändert -> dist-upgrade zu Jessie durchgeführt.

Warum das nicht auch bei einem nicht ganz frischen Wheezy funktionert – keine Ahnung. Nachti. :)