Fehlerbehebung des RHEL-Bootvorgangs

Einführung

In diesem Lab lernen Sie wichtige Techniken zur Fehlerbehebung und Reparatur des Bootvorgangs von Red Hat Enterprise Linux (RHEL). Sie werden untersuchen, wie Sie in verschiedenen Phasen der Bootsequenz mit dem System interagieren können, um häufige Probleme zu diagnostizieren und zu beheben, die ein korrektes Starten des Systems verhindern können. Dies beinhaltet die Arbeit mit systemd-Bootzielen und die Nutzung spezieller Bootmodi, die für die Systemwiederherstellung konzipiert sind.

Während der Übungen sammeln Sie praktische Erfahrungen im Verwalten von systemd-Zielen mit systemctl, im Booten in den Rettungsmodus (rescue mode) über das GRUB-Menü zur Systemwartung und im Zurücksetzen des Root-Passworts mithilfe des Kernel-Parameters rd.break. Darüber hinaus lernen Sie, wie Sie den Notfallmodus (emergency mode) verwenden, um kritische Fehler in Konfigurationsdateien zu beheben, wie z. B. eine beschädigte /etc/fstab, und so sicherzustellen, dass Sie ein nicht bootfähiges System in einen betriebsbereiten Zustand versetzen können.

Verwalten von Systemd-Bootzielen mit systemctl

In diesem Schritt lernen Sie, wie Sie systemd-Bootziele verwalten. In systemd ist ein "Ziel" (target) ein Synchronisationspunkt, der verschiedene Dienste und andere Einheiten zusammenfasst, die benötigt werden, um das System in einen bestimmten Zustand zu versetzen. Dies ist das moderne Äquivalent der "Runlevel" in älteren SysV-Init-Systemen. Wir werden untersuchen, wie Sie das aktuelle Standardziel anzeigen, das Standardziel für zukünftige Boots ändern und vorübergehend zu einem anderen Ziel wechseln können.

Zuerst wollen wir überprüfen, in welches Ziel Ihr System standardmäßig bootet. 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 Standardziel anzuzeigen, führen Sie den folgenden Befehl aus:

systemctl get-default

Sie sollten sehen, dass das Standardziel das grafische Ziel ist.

graphical.target

Ändern wir nun das Standard-Bootziel auf multi-user.target. Dies ist nützlich für Serverumgebungen oder zur Fehlerbehebung in Situationen, 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 Administratorrechten 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 Standard geändert wurde, indem Sie den Befehl get-default erneut ausführen.

systemctl get-default

Die Ausgabe zeigt nun das neue Standardziel.

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 Standardziel wieder auf graphical.target.

sudo systemctl set-default graphical.target

Sie sehen eine ähnliche Ausgabe wie zuvor, die anzeigt, dass der symbolische Link wieder geändert 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 Standardziel auf graphical.target wiederhergestellt wurde.

systemctl get-default

graphical.target

Zusätzlich zum Ändern des Standardziels für Neustarts können Sie Ziele auch in der aktuellen Sitzung mit systemctl isolate wechseln. Dieser Befehl stoppt Dienste, die nicht mit dem neuen Ziel verknüpft sind, und startet die, die es sind. Beispielsweise würde das Ausführen von sudo systemctl isolate multi-user.target Ihre grafische Sitzung beenden und zu einer reinen Textkonsole wechseln. Dies ist ein leistungsstarker, aber potenziell störender Befehl, daher werden wir ihn hier nicht ausführen.

Sie haben jetzt erfolgreich systemctl verwendet, um Systemd-Ziele zu verwalten.

Booten in den Rettungsmodus (Rescue Mode) über das GRUB-Menü

In diesem Schritt lernen Sie rescue.target kennen, ein spezielles systemd-Ziel, das für die Systemwiederherstellung konzipiert wurde. Auf einem Standard-RHEL-System würden Sie auf diesen Modus zugreifen, indem Sie neu starten, den Bootloader (GRUB) unterbrechen und einen Parameter zu den Bootoptionen des Kernels hinzufügen. Dies bietet eine Single-User-Shell mit eingebundenem Root-Dateisystem und deaktivierten Diensten, was ideal für die Fehlerbehebung ist.

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 Rettungsmodus untersuchen, um zu verstehen, wie er funktioniert.

Zuerst wollen wir die systemd-Unit-Datei für rescue.target finden. Diese Dateien werden typischerweise im Verzeichnis /usr/lib/systemd/system/ gespeichert.

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

Sie sehen die Datei mit ihren Berechtigungen und ihrem Eigentümer 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.

cat /usr/lib/systemd/system/rescue.target

Die Ausgabe zeigt die Definition des Ziels.

##  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 Direktiven in dieser Datei sind:

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

Um eine bessere Vorstellung von der minimalen Umgebung zu bekommen, die der Rettungsmodus bietet, können Sie seine Abhängigkeiten anzeigen. Der Befehl systemctl list-dependencies zeigt alle Einheiten an, die als Teil eines Ziels gestartet werden.

systemctl list-dependencies rescue.target

Die Ausgabe listet die für den Rettungsmodus erforderlichen Einheiten auf. Sie sehen eine minimale Menge an Diensten, was bestätigt, dass es sich um eine optimierte Umgebung handelt, die für Reparaturaufgaben konzipiert wurde.

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
... (output may vary) ...

Die wichtigste Erkenntnis ist, dass rescue.target eine Root-Shell mit dem Dateisystem im Lese-Schreib-Modus bereitstellt, sodass Sie Systemprobleme beheben können. In den folgenden Schritten werden wir Wiederherstellungsszenarien simulieren, 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 wichtige Fähigkeit zur Wiederherstellung. Die Standardmethode beinhaltet das Unterbrechen des Bootvorgangs mit dem Kernel-Parameter rd.break, der Ihnen Zugriff auf eine Shell gewährt, bevor das System vollständig startet.

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

1. Remounten Sie das Root-Dateisystem des Systems (das im Read-Only-Modus unter /sysroot eingebunden ist) im Read-Write-Modus mit dem Befehl mount -o remount,rw /sysroot.
2. Geben Sie eine chroot-Jail unter /sysroot mit chroot /sysroot ein. Dadurch wird das tatsächliche Root-Dateisystem des Systems zu Ihrer aktuellen Umgebung, sodass Sie Befehle ausführen können, die sich auf das System auswirken.
3. Ändern Sie das Passwort mit dem Befehl passwd.
4. Beheben Sie potenzielle SELinux-Kontextprobleme.
5. Verlassen Sie die chroot-Umgebung und die initramfs-Shell, um das Booten 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 Eintritt in die chroot-Umgebung ausführen würden.

Simulieren wir zunächst das Ändern des Root-Passworts. Stellen Sie sich vor, Sie sind erfolgreich in die chroot-Jail eingetreten. Sie hätten jetzt Root-Zugriff, um das Passwort eines beliebigen Benutzers zu ändern. Wir verwenden den Befehl sudo passwd root, um das Passwort des Benutzers root 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 erneut einzugeben (z. B. labex.io).

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

Nachdem Sie das Passwort in dieser Wiederherstellungsumgebung geändert haben, kann der SELinux-Sicherheitskontext für die Passwortdatei (/etc/shadow) falsch werden. Um dies zu beheben, müssen Sie beim nächsten Booten eine vollständige SELinux-Relabeling des Systems erzwingen. Dies geschieht durch 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 <date> <time> /.autorelabel

Auf einem realen System würden Sie jetzt zweimal exit eingeben und das System neu starten lassen. Es würde den langwierigen Relabeling-Prozess durchführen und dann normal mit dem neuen Passwort booten. Da wir dies in unserem Lab nicht auslösen möchten, bereinigen wir, indem wir die Datei, die wir gerade erstellt haben, entfernen.

sudo rm /.autorelabel

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.

Reparieren von /etc/fstab-Fehlern mit dem Notfallmodus (Emergency Mode)

In diesem Schritt lernen Sie, wie Sie Fehler in der Datei /etc/fstab diagnostizieren und reparieren. Diese Datei ist für den Bootvorgang von entscheidender Bedeutung, da sie dem System mitteilt, welche Dateisysteme es einbinden und wo es sie einbinden soll. Ein falscher Eintrag in /etc/fstab kann verhindern, dass das System bootet, und es in den Emergency Mode zwingen.

Der Notfallmodus bietet die minimalstmögliche Umgebung für die Systemreparatur. Im Gegensatz zum Rettungsmodus versucht er nicht, die meisten Dateisysteme einzubinden oder viele Dienste zu starten. Entscheidend ist, dass das Root-Dateisystem (/) im Read-Only-Modus (ro) eingebunden wird, um weitere Schäden zu verhindern.

Obwohl wir in diesem Lab keinen echten Bootfehler auslösen können, können wir den Prozess des Auffindens 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 sich auf ein nicht vorhandenes Gerät bezieht.

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

Betrachten wir nun den Inhalt von /etc/fstab, um zu bestätigen, dass unsere fehlerhafte Zeile hinzugefügt wurde.

cat /etc/fstab

Sie sollten die falsche Zeile am Ende der Datei sehen.

#
## /etc/fstab
## Created by anaconda on <date>
#
## 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 einzubinden, die noch nicht eingebunden sind. Da unser Eintrag ungültig ist, schlägt dieser Befehl fehl.

sudo mount -a

Der Befehl erzeugt einen Fehler, der eindeutig darauf hinweist, dass der Mountpoint /data nicht existiert. Dies ähnelt dem Fehler, den Sie während eines fehlgeschlagenen Bootvorgangs sehen würden.

mount: /data: mount point does not exist.

Simulieren wir nun den Reparaturprozess. In einer realen Notfall-Shell besteht der erste Schritt darin, das Root-Dateisystem im Read-Write-Modus neu einzubinden, um Änderungen zu ermöglichen.

sudo mount -o remount,rw /

Da das Dateisystem jetzt beschreibbar ist, können Sie /etc/fstab bearbeiten, um den Fehler zu beheben. Verwenden Sie den Editor nano, um die Datei zu öffnen.

sudo nano /etc/fstab

Verwenden Sie im nano-Editor die Pfeiltasten, um zur fehlerhaften Zeile (/dev/nonexistent /data xfs defaults 0 0) zu navigieren und sie zu löschen. Sie können die gesamte Zeile löschen, indem Sie Strg+k drücken. Nachdem die Zeile entfernt wurde, speichern Sie die Datei, indem Sie Strg+x, dann y und schließlich Enter drücken.

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

sudo mount -a

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

Zusammenfassung

In diesem Lab haben Sie wesentliche Techniken zur Fehlerbehebung des Red Hat Enterprise Linux-Bootvorgangs gelernt. Sie haben die Verwaltung von systemd-Bootzielen geübt, z. B. das Anzeigen des aktuellen Standardziels und dessen Änderung zwischen graphical.target und multi-user.target mithilfe von systemctl. Sie haben auch gelernt, wie Sie die Bootsequenz unterbrechen können, um auf spezielle Wiederherstellungsumgebungen zuzugreifen, einschließlich des Bootens in den Rettungsmodus (rescue mode) über das GRUB-Menü, um Systemwartungsaufgaben in einer Single-User-Shell auszuführen.

Darüber hinaus haben Sie wichtige Wiederherstellungsverfahren für häufige Systemausfälle ausgeführt. Sie haben erfolgreich ein vergessenes Root-Passwort zurückgesetzt, indem Sie den Kernel-Parameter rd.break verwendet, das Root-Dateisystem mit Schreibberechtigungen neu eingebunden und eine chroot-Umgebung verwendet haben, um ein neues Passwort festzulegen, während Sie gleichzeitig den SELinux-Kontext durch Erstellen einer .autorelabel-Datei berücksichtigt haben. Schließlich haben Sie gelernt, Bootfehler zu beheben, die durch /etc/fstab-Fehler verursacht werden, indem Sie den Notfallmodus (emergency mode) aufrufen, den problematischen Eintrag identifizieren und ihn auskommentieren, um dem System einen erfolgreichen Bootvorgang zu ermöglichen.