systemd rescue.target und emergency.target: aufrufen und zum Normalbetrieb zurückkehren

Ziel

Im Rescue- oder Emergency-Modus booten, um ein System zu reparieren, das sein normales Target nicht erreicht, und anschliessend zum Normalbetrieb zurückkehren.

Voraussetzungen

Konsolenzugriff, um im Boot-Menü einen Kernel-Parameter zu ergänzen. Ausserdem das Root-Passwort: Beide Shells starten sulogin, das danach fragt. Ist das Root-Konto gesperrt (Standard bei Ubuntu), wird die Shell verweigert, sofern sulogin nicht mit --force läuft. Darauf ist vor einem Ausfall zu achten, oder es ist ein Rescue-Medium zu verwenden.

Schritte

1. Den Unterschied kennen, gemäss systemd.special(7): rescue.target "pulls in the base system (including system mounts) and spawns a rescue shell" (zieht das Basissystem inklusive Mounts nach und startet eine Rescue-Shell). Die meisten Dienste werden nicht gestartet, aber Dateisysteme sind eingehängt und die grundlegende Infrastruktur läuft. emergency.target "starts an emergency shell on the main console" und "does not pull in other services or mounts" (startet eine Emergency-Shell auf der Hauptkonsole und zieht weder andere Dienste noch Mounts nach). Es ist der minimalste Weg zu einer Shell, vergleichbar mit init=/bin/sh, aber mit funktionierendem Service-Manager. systemd wechselt auch von selbst in dieses Target, wenn die Prüfung eines benötigten Dateisystems fehlschlägt oder es sich nicht einhängen lässt.
2. Im Menü des Boot-Loaders die Kernel-Kommandozeile für einen einzelnen Bootvorgang bearbeiten und systemd.unit=rescue.target oder systemd.unit=emergency.target anhängen (die Aliase single bzw. 1 wählen den Rescue-Modus, emergency den Emergency-Modus). Die Änderung gilt nur einmalig; auf die Platte wird nichts geschrieben.
3. Beachten: Ob das Root-Dateisystem im Emergency-Modus schreibbar eingehängt ist, hängt davon ab, wie dieser Modus erreicht wurde. Es kann bereits schreibgeschützt sein (zum Beispiel wenn mit ro gebootet wurde und der Vorgang vor der Stufe scheiterte, die es neu einhängt) oder schreibbar, wenn der Wechsel erst nach den normalen Mounts erfolgte. Vor jedem Schreibzugriff mit mount | grep ' / ' prüfen und bei Bedarf ausdrücklich neu einhängen: mount -o remount,rw /.
4. Die Reparatur durchführen (eine defekte Zeile in /etc/fstab korrigieren, einen beim Booten scheiternden Dienst beheben, einen Fehler in /etc/default/grub berichtigen). Ein vergessenes Root-Passwort lässt sich auf diesem Weg nicht zurücksetzen, da bereits der Einstieg es verlangt. Bei dracut-basierten Systemen hält stattdessen rd.break im initramfs an, bevor das Root-Dateisystem gewechselt wird; das echte Root liegt dann schreibgeschützt unter /sysroot: mount -o remount,rw /sysroot, chroot /sysroot, passwd root, und auf SELinux-Systemen vor dem Verlassen touch /.autorelabel, da sonst der nächste Boot Logins abweisen kann.
5. Zum Normalbetrieb zurückkehren, indem neu gestartet wird (systemctl reboot, diesmal ohne den Parameter systemd.unit=) oder, aus dem Rescue-Modus ohne Neustart, mit systemctl default (auch als systemctl isolate default.target geschrieben), um den Rest des Systems in der laufenden Sitzung hochzufahren.
6. Prüfen: systemctl get-default meldet das konfigurierte Default-Target, und systemctl list-units --failed sollte nach der Rückkehr leer sein (oder nur erwartete Einträge enthalten).

Erwartetes Ergebnis

Das System erreicht eine funktionierende Single-User- oder Emergency-Shell, selbst wenn der normale Boot nicht abgeschlossen werden kann, und kehrt nach der Reparatur sauber zu default.target zurück.

Grenzen und Prüfbasis

Beide Targets werden auf dieselbe Weise erreicht (systemd.unit=); eine häufige Fehlerquelle ist die Verwechslung, welches von beiden angefordert wurde: Rescue liefert eingehängte Dateisysteme und grundlegende Dienste, Emergency nicht. Eine systemd.unit=-Änderung im Boot-Menü wirkt nie über diesen einen Bootvorgang hinaus; eine dauerhafte Änderung gehört in die Konfiguration des Boot-Loaders und nicht hierher.