Dépanner le Processus de Démarrage RHEL

Introduction

Dans ce laboratoire, vous apprendrez des techniques essentielles pour le dépannage et la réparation du 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 pour diagnostiquer et 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 l'utilisation de 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 de secours (rescue mode) à partir du menu GRUB pour la maintenance du système, et la réinitialisation du mot de passe root en utilisant le paramètre du noyau rd.break. De plus, vous apprendrez à utiliser le mode d'urgence (emergency mode) pour réparer les erreurs critiques de fichiers de configuration, telles qu'un /etc/fstab corrompu, vous assurant ainsi de pouvoir restaurer un système non démarrable à 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 certain état. C'est l'équivalent moderne des "runlevels" dans les anciens systèmes SysV init. Nous allons explorer comment afficher la cible par défaut actuelle, modifier la cible par défaut pour les futurs démarrages et basculer temporairement vers une cible différente.

Tout d'abord, vérifions dans quelle cible votre système démarre par défaut. Le graphical.target est utilisé pour les systèmes avec un environnement de bureau, fournissant une interface utilisateur graphique (GUI). Le multi-user.target est destiné à une interface en ligne de commande uniquement.

Pour voir la cible par défaut actuelle, exécutez la commande suivante :

systemctl get-default

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

graphical.target

Maintenant, changeons la cible de démarrage par défaut en multi-user.target. Ceci est utile pour les environnements serveur ou pour le dépannage des situations où l'interface graphique n'est pas nécessaire ou cause des problèmes. La commande systemctl set-default y parvient 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.

systemctl get-default

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

multi-user.target

Avec ce paramètre, le système démarrerait dans une console en mode texte après un redémarrage. Pour ce laboratoire, nous voulons maintenir un environnement graphique cohérent. Remettons la cible par défaut à graphical.target.

sudo systemctl set-default graphical.target

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

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

Exécutez une dernière vérification pour confirmer que la cible par défaut est restaurée à graphical.target.

systemctl get-default

graphical.target

En plus de modifier la cible par défaut pour les redémarrages, vous pouvez également changer de cible dans la session en cours 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.

Démarrer en Mode de Secours depuis le Menu GRUB

Dans cette étape, vous en apprendrez davantage sur 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édez à 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 véritable redémarrage ou accéder au menu GRUB dans cet environnement de laboratoire conteneurisé, nous pouvons toujours explorer la configuration du mode de secours 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 répertorié avec ses permissions et sa propriété.

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

Maintenant, examinons le contenu de ce fichier pour comprendre sa configuration. La commande cat affichera le contenu du fichier dans le terminal.

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

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 root.
• After=sysinit.target rescue.service : Cela spécifie l'ordre d'activation, garantissant que le mode de secours démarre après l'initialisation du système et le service de secours.
• AllowIsolate=yes : Cela vous permet de basculer vers cette cible à partir d'une autre cible en utilisant la commande systemctl isolate rescue.target dans un système en cours d'exécution.

Pour avoir une meilleure idée de l'environnement minimal que le mode de secours fournit, vous pouvez afficher ses dépendances. La commande systemctl list-dependencies affiche toutes les unités qui sont démarrées dans le cadre d'une cible.

systemctl list-dependencies rescue.target

La sortie répertorie les unités requises pour le mode de secours. Vous verrez un ensemble minimal de services, confirmant qu'il s'agit d'un environnement simplifié 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
... (output may vary) ...

L'essentiel 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 du 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 essentielle. La méthode standard consiste à interrompre le processus de démarrage avec le paramètre du 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émarrez, interrompez le chargeur de démarrage GRUB et ajoutez 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 les suivantes :

1. Remonter le système de fichiers racine (qui est monté en lecture seule à /sysroot) en mode lecture-écriture avec la commande mount -o remount,rw /sysroot.
2. Entrer dans un environnement chroot à /sysroot avec chroot /sysroot. Cela fait du système de fichiers racine réel de votre système votre environnement actuel, vous permettant d'exécuter des commandes qui affectent le système.
3. Modifier le mot de passe à l'aide de la commande passwd.
4. Résoudre les problèmes potentiels de contexte SELinux.
5. Quitter le chroot et le shell initramfs pour continuer le démarrage.

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

Tout d'abord, simulons la modification du mot de passe root. Imaginez que vous êtes entré avec succès dans l'environnement chroot. Vous auriez maintenant un accès root pour modifier le mot de passe de n'importe quel utilisateur. Nous utiliserons la commande sudo passwd root pour modifier 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é à entrer et à ressaisir le nouveau mot de passe (par exemple, labex.io).

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

Après avoir modifié le mot de passe dans cet environnement de récupération, le contexte de sécurité SELinux sur le fichier de mot de passe (/etc/shadow) peut devenir incorrect. Pour corriger cela, vous devez forcer une réétiquette complète 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 été créé.

ls -l /.autorelabel

La sortie doit afficher le fichier nouvellement créé.

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

Sur un système réel, 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. Puisque nous ne voulons pas déclencher cela dans notre laboratoire, nous allons nettoyer en supprimant le fichier que nous venons de créer.

sudo rm /.autorelabel

Cela 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 Urgence

Dans cette étape, vous apprendrez à diagnostiquer et à réparer les erreurs dans le fichier /etc/fstab. Ce fichier est essentiel au 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 d'urgence.

Le mode d'urgence fournit l'environnement le plus minimal possible pour la réparation du système. Contrairement au mode de secours, il ne tente pas de monter la plupart des systèmes de fichiers ou de démarrer de nombreux services. De manière cruciale, le système de fichiers racine (/) est monté en mode lecture seule (ro) pour éviter d'autres dommages.

Bien que nous ne puissions pas déclencher une véritable défaillance au démarrage dans ce laboratoire, nous pouvons simuler le processus de recherche et de correction d'une erreur /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, affichons le contenu de /etc/fstab pour confirmer que notre mauvaise ligne a été ajoutée.

cat /etc/fstab

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 allons simuler l'étape de diagnostic. La commande mount -a tente de monter tous les systèmes de fichiers répertoriés dans /etc/fstab qui ne sont pas déjà montés. Puisque notre entrée est invalide, cette commande échouera.

sudo mount -a

La commande produira une erreur, indiquant clairement que le point de montage /data n'existe pas. Ceci est similaire à l'erreur que vous verriez lors d'un démarrage ayant échoué.

mount: /data: mount point does not exist.

Maintenant, simulons le processus de réparation. Dans un véritable 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 /

Avec le système de fichiers maintenant accessible en écriture, vous pouvez modifier /etc/fstab pour corriger l'erreur. Utilisez l'éditeur nano pour ouvrir le fichier.

sudo nano /etc/fstab

À l'intérieur de l'éditeur nano, utilisez les touches fléchées pour naviguer jusqu'à la ligne défectueuse (/dev/nonexistent /data xfs defaults 0 0) et la supprimer. Vous pouvez supprimer la ligne entière en appuyant sur Ctrl+k. Une fois la ligne supprimée, enregistrez le fichier en appuyant sur Ctrl+x, puis sur y, et enfin sur Entrée.

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éussi à réparer le fichier.

Résumé

Dans ce laboratoire, vous avez appris des techniques essentielles pour le dépannage du processus de démarrage de Red Hat Enterprise Linux. Vous avez pratiqué la gestion des cibles de démarrage systemd, telles que l'affichage du défaut actuel et son changement entre graphical.target et multi-user.target en utilisant 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 le démarrage en mode de secours à partir du menu GRUB pour effectuer des tâches de maintenance du 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éussi à réinitialiser un mot de passe root oublié en utilisant le paramètre du 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 également 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 /etc/fstab en entrant en mode d'urgence, en identifiant l'entrée problématique et en la commentant pour permettre au système de démarrer avec succès.