Rescue- oder Live-System booten und per chroot in ein installiertes Linux wechseln, um es zu reparieren

Ziel

Ein installiertes Linux-System von einem unabhängigen Rescue- oder Live-Medium aus reparieren, indem die eigenen Programme des installierten Systems per chroot genutzt werden. Typische Fälle: einen Bootloader neu installieren, ein Paket reparieren, ein Passwort zurücksetzen oder eine Konfiguration bearbeiten, die das installierte System mangels ausreichenden Bootvorgangs nicht mehr selbst bearbeiten kann.

Voraussetzungen

Ein Rescue- oder Live-Medium (Rescue-Modus des Installers, Live-USB-Stick oder Cloud-Rescue-Image) mit kompatibler CPU-Architektur; Root-Rechte auf diesem Medium; die installierten Datenträger sind für das Medium sichtbar, eine allfällige Verschlüsselungs-Passphrase liegt bereit.

Schritte

1. Rescue-/Live-Medium booten und die Root-Partition des installierten Systems identifizieren: mit lsblk -f oder blkid die Dateisystem-Labels bzw. UUIDs mit den Einträgen in der /etc/fstab des installierten Systems abgleichen.
2. Das installierte Root-Dateisystem in ein Arbeitsverzeichnis einhängen, zum Beispiel mit mount /dev/<root-partition> /mnt (bei Btrfs das Root-Subvolume angeben, z. B. -o subvol=@ unter Ubuntu oder -o subvol=root unter Fedora). Liegen /boot oder /boot/efi auf separaten Partitionen, diese vor dem Fortfahren in den entsprechenden Unterverzeichnissen unter /mnt einhängen – die chroot-Umgebung muss sie unter den Pfaden sehen, die das installierte System erwartet.
3. Die virtuellen Dateisysteme des Kernels im Zielsystem sichtbar machen: for d in dev proc sys run; do mount --rbind /$d /mnt/$d; mount --make-rslave /mnt/$d; done. --rbind übernimmt auch untergeordnete Mounts wie /dev/pts und, auf einem im UEFI-Modus gebooteten Rescue-System, /sys/firmware/efi/efivars; ein einfaches --bind von /sys enthält efivarfs nicht (in diesem Fall mit mount -t efivarfs efivarfs /mnt/sys/firmware/efi/efivars einhängen). --make-rslave verhindert, dass sich ein späteres rekursives Aushängen auf das Rescue-System zurückauswirkt. Das Rescue-Medium muss selbst im UEFI-Modus gebootet sein, sonst gibt es keine EFI-Variablen, in die geschrieben werden könnte.
4. In die chroot-Umgebung wechseln: chroot /mnt /bin/bash startet die Shell «with root directory set to» /mnt (chroot(1)), sodass Programme Pfade und Konfiguration aus dem installierten System auflösen.
5. Die Reparatur mit den eigenen Werkzeugen des installierten Systems durchführen. Bootloader, BIOS/MBR: grub-install /dev/<disk> (gesamter Datenträger; unter RHEL grub2-install). UEFI unter Debian/Ubuntu: grub-install --target=x86_64-efi --efi-directory=/boot/efi. UEFI in der RHEL-Familie: grub2-install nicht ausführen (es würde die signierte Secure-Boot-Kette ersetzen); stattdessen die Pakete neu installieren, z. B. dnf reinstall shim-x64 grub2-efi-x64 (erfordert Repository-Zugriff aus der chroot-Umgebung heraus). Anschliessend grub.cfg am Pfad neu erzeugen, den die Distribution verwendet. Weitere Reparaturen: ein Paket neu installieren, /etc/fstab bearbeiten, passwd <user> (auf SELinux-Systemen danach touch /.autorelabel), ein initramfs neu erstellen (dabei die Kernel-Version explizit angeben).
6. Die chroot-Umgebung verlassen, sync ausführen und dann umount -R /mnt. Dieser Befehl hängt Bind-Mounts, /boot/efi, /boot und das Root-Dateisystem in der richtigen Reihenfolge aus. Meldet er, das Ziel sei belegt, den verursachenden Prozess suchen (fuser -vm /mnt), statt das Aushängen zu erzwingen.
7. Neu starten, dabei das Rescue-Medium entfernen, und prüfen, dass das System wieder normal startet.

Erwartetes Ergebnis

Befehle in der chroot-Umgebung verhalten sich so, als würden sie nativ auf dem installierten System ausgeführt; nach dem Aushängen und Neustart bootet das installierte System selbstständig.

Grenzen und Prüfbasis

Eine chroot-Umgebung nutzt den Kernel des Rescue-Systems, nicht den des installierten Systems, und isoliert weder Netzwerk noch Benutzer noch Prozess-IDs – Befehle darin laufen mit vollen Root-Rechten auf dem Host. Verwendet das installierte Root-Dateisystem LVM, RAID oder LUKS, vor dem ersten Mount-Schritt diese Schichten aktivieren (vgchange -ay, mdadm --assemble, cryptsetup open). Ein fehlendes efivarfs in der chroot-Umgebung ist eine häufige Ursache dafür, dass grub-install auf UEFI-Systemen fehlschlägt, da es die EFI-Variablen benötigt, um den Booteintrag zu schreiben.