Dépanner le processus de démarrage de RHEL

Introduction

Dans ce laboratoire, vous apprendrez les techniques essentielles pour dépanner et réparer le processus de démarrage de Red Hat Enterprise Linux (RHEL). Vous explorerez comment interagir avec le système à différentes étapes de la séquence de démarrage afin de diagnostiquer et de résoudre les problèmes courants qui peuvent empêcher un système de démarrer correctement. Cela inclut l'utilisation des cibles de démarrage systemd et des modes de démarrage spécialisés conçus pour la récupération du système.

Tout au long des exercices, vous acquerrez une expérience pratique dans la gestion des cibles systemd avec systemctl, le démarrage en mode rescue depuis le menu GRUB pour la maintenance du système, et la réinitialisation du mot de passe root à l'aide du paramètre de noyau rd.break. De plus, vous apprendrez à utiliser le mode emergency pour réparer des erreurs critiques dans les fichiers de configuration, comme un /etc/fstab corrompu, afin de garantir que vous puissiez restaurer un système non démarrable vers un état opérationnel.

Gérer les cibles de démarrage Systemd avec systemctl

Dans cette étape, vous apprendrez à gérer les cibles de démarrage systemd. Dans systemd, une "cible" (target) est un point de synchronisation qui regroupe divers services et autres unités nécessaires pour amener le système à un état spécifique. Il s'agit de l'équivalent moderne des "niveaux d'exécution" (runlevels) des anciens systèmes SysV init. Nous explorerons comment afficher la cible par défaut actuelle, modifier la cible par défaut pour les démarrages futurs et basculer temporairement vers une cible différente.

Tout d'abord, déplacez-vous dans le répertoire de pratique de ce laboratoire.

cd /home/labex/project

Commençons par vérifier sur quelle cible votre système démarre par défaut. La cible graphical.target est utilisée pour les systèmes dotés d'un environnement de bureau, fournissant une interface utilisateur graphique (GUI). La cible multi-user.target est destinée à une interface en ligne de commande uniquement.

Pour voir la cible par défaut actuelle et enregistrer le résultat pour une consultation ultérieure, exécutez la commande suivante :

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

Vous devriez constater que la cible par défaut est la cible graphique.

graphical.target

Maintenant, changeons la cible de démarrage par défaut pour multi-user.target. Ceci est utile pour les environnements serveur ou pour les situations de dépannage où l'interface graphique n'est pas nécessaire ou cause des problèmes. La commande systemctl set-default permet d'y parvenir en modifiant le lien symbolique /etc/systemd/system/default.target.

Utilisez sudo pour exécuter cette commande avec des privilèges administratifs.

sudo systemctl set-default multi-user.target

La sortie confirme que le lien symbolique a été mis à jour.

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

Vous pouvez vérifier que la valeur par défaut a été modifiée en exécutant à nouveau la commande get-default et en enregistrant le résultat.

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

La sortie affiche désormais la nouvelle cible par défaut.

multi-user.target

Avec ce paramètre, le système démarrerait sur une console textuelle après un redémarrage. Pour ce laboratoire, nous souhaitons conserver un environnement graphique cohérent. Remettons la cible par défaut sur graphical.target.

sudo systemctl set-default graphical.target

Vous verrez une sortie similaire à la précédente, indiquant que le lien symbolique a été rétabli.

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

Effectuez une vérification finale pour confirmer que la cible par défaut est bien revenue à graphical.target, et enregistrez le résultat.

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

graphical.target

En plus de modifier la cible par défaut pour les redémarrages, vous pouvez également basculer de cible dans la session actuelle en utilisant systemctl isolate. Cette commande arrête les services non associés à la nouvelle cible et démarre ceux qui le sont. Par exemple, l'exécution de sudo systemctl isolate multi-user.target mettrait fin à votre session graphique et basculerait vers une console en mode texte uniquement. Il s'agit d'une commande puissante mais potentiellement perturbatrice, nous ne l'exécuterons donc pas ici.

Vous avez maintenant utilisé avec succès systemctl pour gérer les cibles systemd.

Dans cette étape, vous découvrirez rescue.target, une cible systemd spéciale conçue pour la récupération du système. Sur un système RHEL standard, vous accéderiez à ce mode en redémarrant, en interrompant le chargeur de démarrage (GRUB) et en ajoutant un paramètre aux options de démarrage du noyau. Cela fournit un shell mono-utilisateur avec le système de fichiers racine monté et la plupart des services désactivés, ce qui est idéal pour le dépannage.

Bien que nous ne puissions pas effectuer un redémarrage réel ou accéder au menu GRUB dans cet environnement de laboratoire conteneurisé, nous pouvons tout de même explorer la configuration du mode rescue pour comprendre son fonctionnement.

Tout d'abord, localisons le fichier d'unité systemd pour rescue.target. Ces fichiers sont généralement stockés dans le répertoire /usr/lib/systemd/system/.

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

Vous verrez le fichier listé avec ses permissions et son propriétaire.

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

Examinons maintenant le contenu de ce fichier pour comprendre sa configuration. La commande cat affichera le contenu du fichier dans le terminal, et tee en enregistrera une copie dans votre répertoire de travail.

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

La sortie montre la définition de la cible.

##  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

Les directives clés dans ce fichier incluent :

Description=Rescue Mode : Un nom lisible par l'homme pour la cible.
Requires=sysinit.target rescue.service : Cela garantit que sysinit.target (initialisation de base du système) et rescue.service sont démarrés lorsque cette cible est activée. Le service de secours fournit le shell de maintenance racine.
After=sysinit.target rescue.service : Cela spécifie l'ordre d'activation, garantissant que le mode rescue démarre après l'initialisation du système et le service de secours.
AllowIsolate=yes : Cela vous permet de basculer vers cette cible depuis une autre cible en utilisant la commande systemctl isolate rescue.target sur un système en cours d'exécution.

Pour avoir une meilleure idée de l'environnement minimal fourni par le mode rescue, vous pouvez visualiser ses dépendances. La commande systemctl list-dependencies affiche toutes les unités qui sont démarrées dans le cadre d'une cible. Enregistrez également cette sortie.

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

La sortie liste les unités requises pour le mode rescue. Vous verrez un ensemble minimal de services, confirmant qu'il s'agit d'un environnement rationalisé conçu pour les tâches de réparation.

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
... (la sortie peut varier) ...

L'essentiel à retenir est que rescue.target fournit un shell root avec le système de fichiers monté en lecture-écriture, vous permettant de corriger les problèmes système. Dans les étapes suivantes, nous simulerons des scénarios de récupération qui reposent sur des principes similaires.

Réinitialiser le mot de passe root avec rd.break et chroot

Dans cette étape, vous apprendrez la procédure pour réinitialiser un mot de passe root perdu sur un système RHEL. Il s'agit d'une compétence de récupération critique. La méthode standard consiste à interrompre le processus de démarrage avec le paramètre de noyau rd.break, ce qui vous donne accès à un shell avant que le système ne démarre complètement.

Sur une machine physique ou virtuelle, vous redémarreriez, interrompriez le chargeur de démarrage GRUB et ajouteriez rd.break à la fin de la ligne du noyau linux. Cette action arrête le processus de démarrage juste avant que systemd ne prenne le contrôle, vous plaçant dans un shell initramfs. À partir de là, les étapes générales sont :

Remonter le système de fichiers racine du système (qui est monté en lecture seule sur /sysroot) en mode lecture-écriture avec la commande mount -o remount,rw /sysroot.
Entrer dans une prison chroot sur /sysroot avec chroot /sysroot. Cela fait du système de fichiers racine réel du système votre environnement actuel, vous permettant d'exécuter des commandes qui affectent le système.
Changer le mot de passe en utilisant la commande passwd.
Gérer les problèmes potentiels de contexte SELinux.
Quitter le chroot et le shell initramfs pour poursuivre le démarrage.

Bien que nous ne puissions pas effectuer un redémarrage réel et utiliser rd.break dans cet environnement de laboratoire, nous simulerons les commandes les plus importantes que vous exécuteriez après être entré dans l'environnement chroot.

Tout d'abord, simulons le changement du mot de passe root. Imaginez que vous avez réussi à entrer dans la prison chroot. Vous auriez maintenant un accès root pour changer le mot de passe de n'importe quel utilisateur. Nous utiliserons la commande sudo passwd root pour changer le mot de passe de l'utilisateur root. Lorsque vous y êtes invité, définissez le nouveau mot de passe sur redhat.

sudo passwd root

Vous serez invité à saisir et à confirmer le nouveau mot de passe. Définissez-le sur redhat.

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

Après avoir changé le mot de passe dans cet environnement de récupération, le contexte de sécurité SELinux sur le fichier de mots de passe (/etc/shadow) peut devenir incorrect. Pour corriger cela, vous devez forcer un réétiquetage complet du système SELinux au prochain démarrage. Cela se fait en créant un fichier vide nommé .autorelabel dans le répertoire racine (/).

sudo touch /.autorelabel

Vérifions que le fichier a bien été créé.

ls -l /.autorelabel

La sortie devrait afficher le fichier nouvellement créé.

-rw-r--r--. 1 root root 0 <date> <time> /.autorelabel

Sur un vrai système, vous taperiez maintenant exit deux fois et laisseriez le système redémarrer. Il effectuerait le long processus de réétiquetage, puis démarrerait normalement avec le nouveau mot de passe. Laissez le fichier /.autorelabel en place pour vérification dans ce laboratoire ; l'étape de vérification le supprimera automatiquement après vérification.

Ceci conclut la simulation de la réinitialisation du mot de passe root. Vous avez pratiqué les commandes clés (passwd et touch /.autorelabel) qui sont au cœur du processus de récupération.

Réparer les erreurs /etc/fstab en mode Emergency

Dans cette étape, vous apprendrez à diagnostiquer et à réparer les erreurs dans le fichier /etc/fstab. Ce fichier est critique pour le processus de démarrage car il indique au système quels systèmes de fichiers monter et où. Une entrée incorrecte dans /etc/fstab peut empêcher le système de démarrer, le forçant à passer en mode emergency.

Le mode emergency fournit l'environnement le plus minimal possible pour la réparation du système. Contrairement au mode rescue, il ne tente pas de monter la plupart des systèmes de fichiers ni de démarrer de nombreux services. Surtout, le système de fichiers racine (/) est monté en mode lecture seule (ro) pour éviter tout dommage supplémentaire.

Bien que nous ne puissions pas déclencher une panne de démarrage réelle dans ce laboratoire, nous pouvons simuler le processus de recherche et de correction d'une erreur dans /etc/fstab.

Tout d'abord, ajoutons intentionnellement une entrée erronée à /etc/fstab. Nous utiliserons la commande echo avec sudo pour ajouter une ligne qui fait référence à un périphérique inexistant.

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

Maintenant, visualisons le contenu de /etc/fstab pour confirmer que notre mauvaise ligne a été ajoutée, et enregistrons une copie avant de la réparer.

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

Vous devriez voir la ligne incorrecte à la fin du fichier.

#
## /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

Ensuite, nous simulerons l'étape de diagnostic. La commande mount -a tente de monter tous les systèmes de fichiers listés dans /etc/fstab qui ne sont pas déjà montés. Comme notre entrée est invalide, cette commande échouera. Enregistrez la sortie d'erreur afin de pouvoir la comparer avec l'état réparé plus tard.

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

La commande produira une erreur, indiquant clairement que la mauvaise entrée /dev/nonexistent ne peut pas être montée. C'est similaire au type d'erreur que vous verriez lors d'un démarrage échoué.

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

Maintenant, simulons le processus de réparation. Dans un vrai shell d'urgence, la première étape consiste à remonter le système de fichiers racine en mode lecture-écriture pour permettre les modifications.

sudo mount -o remount,rw /

Le système de fichiers étant maintenant accessible en écriture, vous pouvez modifier /etc/fstab pour corriger l'erreur. Utilisez nano, vi ou un autre éditeur de terminal avec lequel vous êtes à l'aise pour ouvrir le fichier.

sudo vi /etc/fstab

À l'intérieur de l'éditeur, naviguez jusqu'à la ligne défectueuse (/dev/nonexistent /data xfs defaults 0 0) et supprimez-la, puis enregistrez le fichier.

Pour confirmer la correction, exécutez à nouveau sudo mount -a.

sudo mount -a

Cette fois, la commande devrait s'exécuter silencieusement sans aucune sortie, ce qui indique que toutes les entrées valides dans /etc/fstab sont correctement montées. Vous avez réparé le fichier avec succès.

Résumé

Dans ce laboratoire, vous avez appris les techniques essentielles pour dépanner le processus de démarrage de Red Hat Enterprise Linux. Vous avez pratiqué la gestion des cibles de démarrage systemd, comme l'affichage de la cible par défaut actuelle et son basculement entre graphical.target et multi-user.target à l'aide de systemctl. Vous avez également appris à interrompre la séquence de démarrage pour accéder à des environnements de récupération spécialisés, notamment en démarrant en mode rescue depuis le menu GRUB pour effectuer des tâches de maintenance système dans un shell mono-utilisateur.

De plus, vous avez exécuté des procédures de récupération critiques pour les pannes système courantes. Vous avez réinitialisé avec succès un mot de passe root oublié en utilisant le paramètre de noyau rd.break, en remontant le système de fichiers racine avec des permissions d'écriture, et en utilisant un environnement chroot pour définir un nouveau mot de passe, tout en traitant le contexte SELinux en créant un fichier .autorelabel. Enfin, vous avez appris à résoudre les échecs de démarrage causés par des erreurs dans /etc/fstab en entrant en mode emergency, en identifiant l'entrée problématique et en la commentant pour permettre au système de démarrer avec succès.