Fehlerbehebung beim RHEL-Bootvorgang

Einführung

In diesem Lab lernen Sie grundlegende Techniken zur Fehlerbehebung und Reparatur des Bootvorgangs von Red Hat Enterprise Linux (RHEL) kennen. Sie werden untersuchen, wie Sie in verschiedenen Phasen des Bootvorgangs mit dem System interagieren können, um häufige Probleme zu diagnostizieren und zu beheben, die einen korrekten Systemstart verhindern. Dazu gehört die Arbeit mit systemd-Boot-Targets sowie die Nutzung spezieller Boot-Modi für die Systemwiederherstellung.

Im Laufe der Übungen sammeln Sie praktische Erfahrungen bei der Verwaltung von systemd-Targets mit systemctl, dem Booten in den Rescue-Modus über das GRUB-Menü zur Systemwartung und dem Zurücksetzen des Root-Passworts mithilfe des Kernel-Parameters rd.break. Darüber hinaus lernen Sie, wie Sie den Emergency-Modus verwenden, um kritische Konfigurationsfehler, wie etwa eine beschädigte /etc/fstab, zu reparieren und so ein nicht mehr startfähiges System wieder in einen betriebsbereiten Zustand zu versetzen.

Verwaltung von systemd-Boot-Targets mit systemctl

In diesem Schritt lernen Sie, wie Sie systemd-Targets verwalten. In systemd ist ein "Target" ein Synchronisationspunkt, der verschiedene Dienste und andere Einheiten gruppiert, die erforderlich sind, um das System in einen bestimmten Zustand zu versetzen. Dies ist das moderne Äquivalent zu den "Runlevels" in älteren SysV-Init-Systemen. Wir werden untersuchen, wie man das aktuelle Standard-Target anzeigt, das Standard-Target für zukünftige Systemstarts ändert und temporär zu einem anderen Target wechselt.

Wechseln Sie zunächst in das Arbeitsverzeichnis für dieses Lab.

cd /home/labex/project

Überprüfen wir zunächst, mit welchem Target Ihr System standardmäßig startet. Das graphical.target wird für Systeme mit einer Desktop-Umgebung verwendet und stellt eine grafische Benutzeroberfläche (GUI) bereit. Das multi-user.target ist für eine reine Befehlszeilenschnittstelle vorgesehen.

Um das aktuelle Standard-Target anzuzeigen und das Ergebnis zur späteren Überprüfung zu speichern, führen Sie den folgenden Befehl aus:

systemctl get-default | tee step1-initial-target.txt

Sie sollten sehen, dass das Standard-Target das grafische Target ist.

graphical.target

Ändern wir nun das Standard-Boot-Target auf multi-user.target. Dies ist nützlich für Serverumgebungen oder für Fehlerbehebungssituationen, in denen die grafische Oberfläche nicht benötigt wird oder Probleme verursacht. Der Befehl systemctl set-default erreicht dies durch Ändern des symbolischen Links /etc/systemd/system/default.target.

Verwenden Sie sudo, um diesen Befehl mit administrativen Rechten auszuführen.

sudo systemctl set-default multi-user.target

Die Ausgabe bestätigt, dass der symbolische Link aktualisiert wurde.

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Sie können überprüfen, ob der Standardwert geändert wurde, indem Sie den Befehl get-default erneut ausführen und das Ergebnis speichern.

systemctl get-default | tee step1-multi-user-target.txt

Die Ausgabe zeigt nun das neue Standard-Target.

multi-user.target

Mit dieser Einstellung würde das System nach einem Neustart in eine textbasierte Konsole booten. Für dieses Lab möchten wir eine konsistente grafische Umgebung beibehalten. Setzen wir das Standard-Target wieder auf graphical.target zurück.

sudo systemctl set-default graphical.target

Sie sehen eine ähnliche Ausgabe wie zuvor, die anzeigt, dass der symbolische Link zurückgesetzt wurde.

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.

Führen Sie eine abschließende Überprüfung durch, um zu bestätigen, dass das Standard-Target wieder auf graphical.target eingestellt ist, und speichern Sie das Ergebnis.

systemctl get-default | tee step1-final-target.txt

graphical.target

Zusätzlich zum Ändern des Standard-Targets für Neustarts können Sie in der aktuellen Sitzung mit systemctl isolate zwischen Targets wechseln. Dieser Befehl stoppt Dienste, die nicht mit dem neuen Target verknüpft sind, und startet die erforderlichen Dienste. Zum Beispiel würde die Ausführung von sudo systemctl isolate multi-user.target Ihre grafische Sitzung beenden und zu einer reinen Textkonsole wechseln. Dies ist ein mächtiger, aber potenziell störender Befehl, daher führen wir ihn hier nicht aus.

Sie haben nun erfolgreich systemctl zur Verwaltung von systemd-Targets verwendet.

Booten in den Rescue-Modus über das GRUB-Menü

In diesem Schritt lernen Sie das rescue.target kennen, ein spezielles systemd-Target, das für die Systemwiederherstellung konzipiert ist. Auf einem Standard-RHEL-System würden Sie auf diesen Modus zugreifen, indem Sie das System neu starten, den Bootloader (GRUB) unterbrechen und einen Parameter zu den Boot-Optionen des Kernels hinzufügen. Dies bietet eine Single-User-Shell, bei der das Root-Dateisystem eingehängt und die meisten Dienste deaktiviert sind – ideal für die Fehlerbehebung.

Obwohl wir in dieser containerisierten Lab-Umgebung keinen echten Neustart durchführen oder auf das GRUB-Menü zugreifen können, können wir dennoch die Konfiguration des Rescue-Modus untersuchen, um dessen Funktionsweise zu verstehen.

Suchen wir zunächst die systemd-Unit-Datei für rescue.target. Diese Dateien werden normalerweise im Verzeichnis /usr/lib/systemd/system/ gespeichert.

ls -l /usr/lib/systemd/system/rescue.target

Sie sehen die Datei mit ihren Berechtigungen und dem Besitzer aufgelistet.

-rw-r--r--. 1 root root 500 Nov  1  2022 /usr/lib/systemd/system/rescue.target

Untersuchen wir nun den Inhalt dieser Datei, um ihre Konfiguration zu verstehen. Der Befehl cat zeigt den Inhalt der Datei im Terminal an, und tee speichert eine Kopie in Ihrem Arbeitsverzeichnis.

cat /usr/lib/systemd/system/rescue.target | tee /home/labex/project/rescue-target.txt

Die Ausgabe zeigt die Definition des Targets.

##  SPDX-License-Identifier: LGPL-2.1-or-later
#
##  This file is part of systemd.
#
##  systemd is free software; you can redistribute it and/or modify it
##  under the terms of the GNU Lesser General Public License as published by
##  the Free Software Foundation; either version 2.1 of the License, or
##  (at your option) any later version.

[Unit]
Description=Rescue Mode
Documentation=man:systemd.special(7)
Requires=sysinit.target rescue.service
After=sysinit.target rescue.service
AllowIsolate=yes

Wichtige Anweisungen in dieser Datei sind:

Description=Rescue Mode: Ein für Menschen lesbarer Name für das Target.
Requires=sysinit.target rescue.service: Dies stellt sicher, dass sowohl sysinit.target (grundlegende Systeminitialisierung) als auch rescue.service gestartet werden, wenn dieses Target aktiviert wird. Der Rescue-Service stellt die Root-Wartungs-Shell bereit.
After=sysinit.target rescue.service: Dies legt die Reihenfolge der Aktivierung fest und stellt sicher, dass der Rescue-Modus nach der Systeminitialisierung und dem Rescue-Service startet.
AllowIsolate=yes: Dies ermöglicht es Ihnen, von einem anderen Target aus mit dem Befehl systemctl isolate rescue.target in einem laufenden System zu diesem Target zu wechseln.

Um eine bessere Vorstellung von der minimalen Umgebung zu bekommen, die der Rescue-Modus bietet, können Sie dessen Abhängigkeiten anzeigen. Der Befehl systemctl list-dependencies zeigt alle Units an, die als Teil eines Targets gestartet werden. Speichern Sie auch diese Ausgabe.

systemctl list-dependencies rescue.target | tee /home/labex/project/rescue-dependencies.txt

Die Ausgabe listet die für den Rescue-Modus erforderlichen Units auf. Sie werden eine minimale Anzahl von Diensten sehen, was bestätigt, dass es sich um eine schlanke Umgebung handelt, die für Reparaturaufgaben ausgelegt ist.

rescue.target
○ ├─rescue.service
○ ├─systemd-update-utmp-runlevel.service
● └─sysinit.target
●   ├─dev-hugepages.mount
●   ├─dev-mqueue.mount
●   ├─dracut-shutdown.service
○   ├─iscsi-onboot.service
○   ├─iscsi-starter.service
●   ├─kmod-static-nodes.service
●   ├─ldconfig.service
●   ├─lvm2-lvmpolld.socket
... (Ausgabe kann variieren) ...

Die wichtigste Erkenntnis ist, dass rescue.target eine Root-Shell mit schreibgeschützt eingehängtem Dateisystem bereitstellt, was es Ihnen ermöglicht, Systemprobleme zu beheben. In den folgenden Schritten simulieren wir Wiederherstellungsszenarien, die auf ähnlichen Prinzipien basieren.

Zurücksetzen des Root-Passworts mit rd.break und chroot

In diesem Schritt lernen Sie das Verfahren zum Zurücksetzen eines verlorenen Root-Passworts auf einem RHEL-System. Dies ist eine kritische Wiederherstellungsfähigkeit. Die Standardmethode beinhaltet das Unterbrechen des Bootvorgangs mit dem Kernel-Parameter rd.break, wodurch Sie Zugriff auf eine Shell erhalten, bevor das System vollständig startet.

Auf einem physischen oder virtuellen Computer würden Sie neu starten, den GRUB-Bootloader unterbrechen und rd.break am Ende der linux-Kernel-Zeile hinzufügen. Diese Aktion stoppt den Bootvorgang kurz bevor systemd die Kontrolle übernimmt und versetzt Sie in eine initramfs-Shell. Von dort aus sind die allgemeinen Schritte:

Einhängen des Root-Dateisystems des Systems (das unter /sysroot schreibgeschützt eingehängt ist) im Lese-Schreib-Modus mit dem Befehl mount -o remount,rw /sysroot.
Wechseln in ein chroot-Jail unter /sysroot mit chroot /sysroot. Dies macht das tatsächliche Root-Dateisystem des Systems zu Ihrer aktuellen Umgebung, sodass Sie Befehle ausführen können, die das System betreffen.
Ändern des Passworts mit dem Befehl passwd.
Behandeln potenzieller SELinux-Kontextprobleme.
Verlassen des chroot und der initramfs-Shell, um den Bootvorgang fortzusetzen.

Obwohl wir in dieser Lab-Umgebung keinen echten Neustart durchführen und rd.break verwenden können, simulieren wir die wichtigsten Befehle, die Sie nach dem Betreten der chroot-Umgebung ausführen würden.

Simulieren wir zunächst das Ändern des Root-Passworts. Stellen Sie sich vor, Sie hätten das chroot-Jail erfolgreich betreten. Sie hätten nun Root-Zugriff, um das Passwort eines beliebigen Benutzers zu ändern. Wir verwenden den Befehl sudo passwd root, um das Passwort des root-Benutzers zu ändern. Wenn Sie dazu aufgefordert werden, setzen Sie das neue Passwort auf redhat.

sudo passwd root

Sie werden aufgefordert, das neue Passwort einzugeben und zu bestätigen. Setzen Sie es auf redhat.

Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Nach dem Ändern des Passworts in dieser Wiederherstellungsumgebung kann der SELinux-Sicherheitskontext der Passwortdatei (/etc/shadow) inkorrekt werden. Um dies zu beheben, müssen Sie beim nächsten Systemstart eine vollständige SELinux-Neukennzeichnung (Relabeling) erzwingen. Dies geschieht durch das Erstellen einer leeren Datei namens .autorelabel im Root-Verzeichnis (/).

sudo touch /.autorelabel

Überprüfen wir, ob die Datei erstellt wurde.

ls -l /.autorelabel

Die Ausgabe sollte die neu erstellte Datei anzeigen.

-rw-r--r--. 1 root root 0 <Datum> <Uhrzeit> /.autorelabel

Auf einem echten System würden Sie nun zweimal exit eingeben und das System neu starten lassen. Es würde den langwierigen Neukennzeichnungsprozess durchführen und dann normal mit dem neuen Passwort booten. Lassen Sie die Datei /.autorelabel für die Überprüfung in diesem Lab an Ort und Stelle; der Überprüfungsschritt wird sie nach der Kontrolle automatisch entfernen.

Dies schließt die Simulation des Zurücksetzens des Root-Passworts ab. Sie haben die wichtigsten Befehle (passwd und touch /.autorelabel) geübt, die für den Wiederherstellungsprozess von zentraler Bedeutung sind.

Reparatur von /etc/fstab-Fehlern im Emergency-Modus

In diesem Schritt lernen Sie, wie Sie Fehler in der Datei /etc/fstab diagnostizieren und reparieren. Diese Datei ist für den Bootvorgang entscheidend, da sie dem System mitteilt, welche Dateisysteme wo eingehängt werden sollen. Ein fehlerhafter Eintrag in /etc/fstab kann den Systemstart verhindern und das System in den emergency mode zwingen.

Der Emergency-Modus bietet die minimalste Umgebung, die für eine Systemreparatur möglich ist. Im Gegensatz zum Rescue-Modus versucht er nicht, die meisten Dateisysteme einzuhängen oder viele Dienste zu starten. Entscheidend ist, dass das Root-Dateisystem (/) im schreibgeschützten Modus (ro) eingehängt wird, um weitere Schäden zu verhindern.

Obwohl wir in diesem Lab keinen echten Boot-Fehler auslösen können, können wir den Prozess des Findens und Behebens eines /etc/fstab-Fehlers simulieren.

Fügen wir zunächst absichtlich einen fehlerhaften Eintrag zu /etc/fstab hinzu. Wir verwenden den Befehl echo mit sudo, um eine Zeile anzuhängen, die auf ein nicht existierendes Gerät verweist.

echo '/dev/nonexistent /data xfs defaults 0 0' | sudo tee -a /etc/fstab

Sehen wir uns nun den Inhalt von /etc/fstab an, um zu bestätigen, dass unsere fehlerhafte Zeile hinzugefügt wurde, und speichern Sie eine Kopie, bevor Sie sie reparieren.

cat /etc/fstab | tee /home/labex/project/step4-fstab-before.txt

Sie sollten die fehlerhafte Zeile am Ende der Datei sehen.

#
## /etc/fstab
## Created by anaconda on <Datum>
#
## Accessible filesystems, by reference, are maintained under '/dev/disk/'.
## See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
## After editing this file, run 'systemctl daemon-reload' to update systemd
## units generated from this file.
#
/dev/vda4 / xfs defaults 0 0
/dev/vda2 /boot xfs defaults 0 0
/dev/vda1 /boot/efi vfat umask=0077,shortname=winnt 0 0
/dev/vda3 swap swap defaults 0 0
/dev/nonexistent /data xfs defaults 0 0

Als Nächstes simulieren wir den Diagnoseschritt. Der Befehl mount -a versucht, alle in /etc/fstab aufgeführten Dateisysteme einzuhängen, die noch nicht eingehängt sind. Da unser Eintrag ungültig ist, wird dieser Befehl fehlschlagen. Speichern Sie die Fehlerausgabe, damit Sie sie später mit dem reparierten Zustand vergleichen können.

sudo mount -a 2>&1 | tee /home/labex/project/step4-mount-error.txt

Der Befehl erzeugt einen Fehler, der deutlich anzeigt, dass der fehlerhafte /dev/nonexistent-Eintrag nicht eingehängt werden kann. Dies ähnelt der Art von Fehler, die Sie während eines fehlgeschlagenen Bootvorgangs sehen würden.

mount: /data: fsconfig system call failed: /dev/nonexistent: Can't lookup blockdev.
       dmesg(1) may have more information after failed mount system call.

Simulieren wir nun den Reparaturprozess. In einer echten Emergency-Shell besteht der erste Schritt darin, das Root-Dateisystem im Lese-Schreib-Modus neu einzuhängen, um Änderungen zu ermöglichen.

sudo mount -o remount,rw /

Da das Dateisystem nun beschreibbar ist, können Sie /etc/fstab bearbeiten, um den Fehler zu beheben. Verwenden Sie nano, vi oder einen anderen Terminal-Editor, mit dem Sie vertraut sind, um die Datei zu öffnen.

sudo vi /etc/fstab

Navigieren Sie im Editor zu der fehlerhaften Zeile (/dev/nonexistent /data xfs defaults 0 0), löschen Sie diese und speichern Sie die Datei.

Um die Korrektur zu bestätigen, führen Sie sudo mount -a erneut aus.

sudo mount -a

Diesmal sollte der Befehl lautlos ohne Ausgabe ausgeführt werden, was darauf hinweist, dass alle gültigen Einträge in /etc/fstab korrekt eingehängt sind. Sie haben die Datei erfolgreich repariert.

Zusammenfassung

In diesem Lab haben Sie grundlegende Techniken zur Fehlerbehebung beim Bootvorgang von Red Hat Enterprise Linux kennengelernt. Sie haben die Verwaltung von systemd-Boot-Targets geübt, wie z. B. das Anzeigen des aktuellen Standard-Targets und das Wechseln zwischen graphical.target und multi-user.target mit systemctl. Sie haben außerdem gelernt, wie man den Bootvorgang unterbricht, um auf spezielle Wiederherstellungsumgebungen zuzugreifen, einschließlich des Bootens in den Rescue-Modus über das GRUB-Menü, um Systemwartungsaufgaben in einer Single-User-Shell durchzuführen.

Darüber hinaus haben Sie kritische Wiederherstellungsverfahren für häufige Systemfehler durchgeführt. Sie haben erfolgreich ein vergessenes Root-Passwort zurückgesetzt, indem Sie den Kernel-Parameter rd.break verwendet, das Root-Dateisystem mit Schreibrechten neu eingehängt und eine chroot-Umgebung genutzt haben, um ein neues Passwort festzulegen, während Sie gleichzeitig den SELinux-Kontext durch das Erstellen einer .autorelabel-Datei korrigiert haben. Schließlich haben Sie gelernt, Boot-Fehler, die durch /etc/fstab-Fehler verursacht wurden, zu beheben, indem Sie in den Emergency-Modus gewechselt sind, den problematischen Eintrag identifiziert und auskommentiert haben, damit das System wieder erfolgreich booten kann.