Das hatte ich mir anders vorgestellt: Auf Arbeit gab es ein System das schon einige Jahre auf dem Buckel hat und leider selten Updates gesehen hat. Es läuft dort (noch) ein CentOS 7. Das Update schien eigentlich ganz normal durchgelaufen zu sein:

sudo yum update

Danach ging es wegen des (längst überfälligen) Kernelupdates an den Reboot und dann wurde es weniger lustig… denn die Maschine startet nur noch mit den Meldungen:

default target masked
rescue target masked, freezing

Den exakten Wortlaut habe ich nicht mehr, denn klar: In dem Zustand geht nur noch eine harter Reboot. Immerhin gut, dass die Maschine nicht in irgendeiner Cloud oder einem Rechenzentrum steht.

Auch das manuelle Setzen von etwaigen Parametern in der Grub-Config (Bootloader)

# Use a plain bash, do not start anything
linux16 /vmlinuz-3.10.0-862.6.3.el7.x86_64 root=/dev/mapper/centos_b110--ws01-root ro crashkernel=auto rd.lvm.lv=centos_b110-ws01/root rd.lvm.lv=centos_b110-ws01/swap init=/bin/bash LANG=en_US.UTF-8

# instruct systemd to run the emergency target
linux16 /vmlinuz-3.10.0-862.6.3.el7.x86_64 root=/dev/mapper/centos_b110--ws01-root ro crashkernel=auto rd.lvm.lv=centos_b110-ws01/root rd.lvm.lv=centos_b110-ws01/swap systemd.unit=emergency.target LANG=en_US.UTF-8

brachte nicht den gewünschten Erfolg. Die Internet-Recherche zu dem Thema ist insgesamt eher frustrierend, es gibt wenig hilfreiche Einträge (deshalb jetzt auch hier meine Gedankestütze).

Um zu verstehen was hier nicht ganz so klappt, hilft es zu wissen, dass CentOS eine initial Ramdisk verwendet (initrd oder auch initramfs genannt). Diese hat einen eigenen Parameter welcher ihr mitteilt, welches Programm sie als init nutzen soll, die etwas verbesserte Variante lautet dann:

# instruct systemd to run the emergency target
linux16 /vmlinuz-3.10.0-862.6.3.el7.x86_64 root=/dev/mapper/centos_b110--ws01-root ro crashkernel=auto rd.lvm.lv=centos_b110-ws01/root rd.lvm.lv=centos_b110-ws01/swap rdinit=/bin/bash LANG=en_US.UTF-8

So richtig weiter hat mich das aber auch nicht gebracht, denn in der Shell kann man keine systemctl-Befehle absetzen, es fehlt die Infrastruktur mit ihren ganze Daemons.

Nächster Ansatz war also einen USB-Stick zu erstellen mit einem CentOS-Installer, dieser bietet ein Live-System (Anaconda genannt, nicht zu verwechseln mit dem Python Tool das auch so benannt ist). Mit dem Start ins Live-System (Troubleshooting -> Rescue a CentOS installation) bekommt man dann auch Zugriff auf das Host-System, allerdings immer noch nicht auf das Systemctl (denn der Daemon dazu läuft ja im Live-System und nicht dem betroffenen System).

Es sieht im System eigentlich alles ganz gut aus, nach dem Einrichten des Netzwerks:

#get IP assignement by DHCP
dhclient enp6s0
#Proxy may be required
export https_proxy=your.company.proxy.example.com:3323

konnte man immerhin einmal versuchen ob das Update vollständig war. Da sich herausgestellt hat, dass wohl auch etwas mit der Ramdisk-Erzeugung und Systemd (Versions-Mismatch zwischen der initialen Ramdisk und den Dateien des Systems), habe ich auch einmal die Ramdisks der Kernel-Abbilder neu erzeugen lassen:

dracut --regenerate-all --force

Leider bringt mich das auch nicht weiter, allerdings wirft dracut auch komische Fehlermeldungen über einen Shell-Operator, dem anscheinend ein Parameter fehlt. Leider auch nichts womit man direkt auf das Problem aufmerksam wird das zu Grunde liegt.

Ein Forumseintrag bei Rockylinux hat mich dann ein Stück weiter gebracht: Aus mir nicht ganz nachvollziehbaren Gründen benötigt CentOS eine Datei namens /etc/os-release – die finde ich bei mir im System leider nicht. Aus dem Live-System lässt sich das mit yum wieder einrichten:

yum reinstall centos-release && dracut --regenerate-all --force

Damit sind dann zumindest einmal die Fehlermeldungen von dracut Geschichte, das klingt schon einmal vielversprechend.

Zudem bin ich mir nicht ganz sicher ob das System beim Update wirklich vollständig sauber aktualisiert wurde, installiere ich alle jetzt installierten Packages nochmal neu. Das hat den Vorteil, dass dabei keinerlei Config-Dateien angefasst werden, aber das System zumindest wieder in einem definierten Zustand ist.

yum reinstall $(yum list installed | awk '{print $1}')

Nun könnte man meinen alles sei wieder gut und auf den ersten Blick sieht das Ergebnis auch wieder viel besser aus: Das System kommt wieder halbwegs auf die Beine und findet auch die targets. Allerdings scheint das System dann endlos beim Schreiben der utmp-Informationen zu hängen.

Zur letzten Meldung der UTMP-Probleme gibt es zwar einige Infos im Netz, aber nichts was mich weiter bringt. An dieser Stelle hilft es das Log etwas weiter zurück durchzugehen. Da wird eine Meldung ausgegeben welche darüber informiert das ein Relabeling von SELinux aus getriggert wurde (was so erst einmal korrekt ist) und auch dass es eine ganze Weile dauern kann bis das durchgelaufen ist. Hier hilft abschließend wirklich nur Geduld. Man hat leider keine brauchbare Möglichkeit zu sehen was da gemacht wird oder auch nur eine Art Status-Indikator über den Fortgang. Einzig, dass die HDD kräftig was zu tun hat sieht man an der entsprechenden LED am Gehäuse.

Wenn man dann lange genug wartet (bei mir waren es fast 90 Minuten, in denen ich weiter recherchiert habe), dann bootet das System auch irgendwann vollständig.

So viel zum Thema: Mach mal „schnell“ Sicherheitsupdates.