Dépanner le démarrage et entrer en rescue sur RHEL 10

Le scénario classique du sysadmin commence par un message simple : « le serveur ne démarre plus ». Sur RHCSA EX200 v10, ce scénario apparaît systématiquement sous une forme ou une autre — mot de passe root oublié, /etc/fstab cassé, GRUB corrompu, service défaillant au boot. Ce tutoriel présente les techniques de récupération sur Red Hat Enterprise Linux 10, depuis l’interruption de GRUB 2 jusqu’au chroot depuis un média externe, en passant par les modes rescue et emergency.

Prérequis avant de commencer

• Un système RHEL 10, Rocky Linux 10 ou AlmaLinux 10 fonctionnel pour s’entraîner sans risque.
• Un ISO d’installation disponible localement, indispensable pour les scénarios où GRUB est cassé.
• Accès à la console — physique sur serveur, ou virtuelle via l’hyperviseur en VM.
• Niveau attendu : intermédiaire à avancé. Temps estimé : 90 minutes.

Étape 1 — Comprendre la séquence de démarrage

RHEL 10 démarre selon une séquence précise : firmware UEFI ou BIOS, GRUB 2, noyau Linux, initramfs, basculement vers /sysroot, démarrage de systemd qui active la cible par défaut. Chaque étape est un point de défaillance potentiel, et chaque étape se diagnostique différemment. Avant d’engager une procédure de récupération, il est utile de savoir où la séquence s’est interrompue.

journalctl --boot=-1 -p err              # Erreurs du boot précédent
journalctl --boot=0 -p err               # Erreurs du boot courant
systemd-analyze blame | head -10
systemd-analyze critical-chain

La sortie de journalctl --boot=-1 consulte le journal du dernier boot avant celui en cours, utile quand on a réussi à redémarrer après une panne. systemd-analyze blame liste les services par durée d’initialisation décroissante : un service à 30 secondes ralentit visiblement le boot. critical-chain montre la chaîne de dépendances la plus longue, ce qui pointe précisément où optimiser.

Étape 2 — Interrompre GRUB 2 au démarrage

Au démarrage, GRUB 2 affiche pendant cinq secondes le menu de sélection. Une pression sur n’importe quelle touche fige le menu. Pour modifier l’entrée sélectionnée avant de la lancer, on appuie sur la touche e. L’éditeur de paramètres apparaît avec la configuration de l’entrée.

Dans cet éditeur, on cherche la ligne qui commence par linux ou linuxefi. C’est sur cette ligne que l’on ajoute des paramètres de noyau. La touche End place le curseur en fin de ligne, ce qui permet d’ajouter sans risque de mauvaise insertion. Une fois les paramètres ajoutés, Ctrl+X ou F10 démarre l’entrée modifiée. Les modifications ne sont pas persistantes — elles concernent uniquement ce démarrage.

Étape 3 — Mode rescue (single user)

Le mode rescue démarre un système minimal avec quelques services systemd activés (réseau, résolution DNS), et propose un shell root après vérification du mot de passe root. C’est le mode pour réparer une configuration sans interférence d’un éventuel service défaillant.

# Dans l'éditeur GRUB, ajouter à la ligne linux :
systemd.unit=rescue.target
# Puis Ctrl+X

Le système démarre en mode rescue et demande le mot de passe root pour accéder au shell. Une fois la session ouverte, l’environnement est complet : on peut éditer des fichiers, désactiver un service avec systemctl disable, corriger /etc/fstab. Pour revenir au mode normal, systemctl default bascule à la cible par défaut sans reboot ; systemctl reboot redémarre proprement.

Étape 4 — Réinitialiser un mot de passe root oublié

Le scénario le plus emblématique de RHCSA. La procédure officielle utilise rd.break qui interrompt la séquence avant le passage à /sysroot, ce qui donne accès à un shell initramfs avec le système monté en lecture seule.

# Dans l'éditeur GRUB, ajouter à la ligne linux :
rd.break enforcing=0
# Puis Ctrl+X
# Au shell switch_root, exécuter :
mount -o remount,rw /sysroot
chroot /sysroot
passwd root
# Saisir le nouveau mot de passe deux fois
touch /.autorelabel
exit
exit

La paire rd.break enforcing=0 est essentielle : rd.break interrompt avant la bascule, et enforcing=0 désactive temporairement SELinux pour éviter qu’il ne refuse le changement de mot de passe et le relabel automatique. Le fichier /.autorelabel demande à SELinux de relabeller l’ensemble du système au prochain boot — étape obligatoire après modification de /etc/shadow en mode dégradé. Sans ce fichier, le boot suivant échouera silencieusement avec des contextes SELinux incohérents. Le double exit referme le chroot puis le shell initramfs, et systemd reprend le démarrage normalement avec le nouveau mot de passe.

Étape 5 — Mode emergency

Plus minimal que rescue, le mode emergency ne démarre quasiment rien — pas de réseau, système monté en lecture seule. Utile quand rescue lui-même échoue, par exemple à cause d’un /etc/fstab qui empêche le montage de /var.

# Dans GRUB :
systemd.unit=emergency.target
# Au shell, le système est en lecture seule
mount -o remount,rw /
vim /etc/fstab
# Commenter la ligne fautive
mount -a
systemctl reboot

Le shell emergency exige le mot de passe root. Le système est monté en lecture seule pour limiter la casse en cas de système de fichiers corrompu ; le remount,rw / autorise les modifications. La commande mount -a teste les nouvelles entrées fstab sans reboot, ce qui évite la boucle d’erreur si une autre ligne reste fautive. Le reboot termine la réparation.

Étape 6 — Démarrer depuis l’ISO d’installation

Quand GRUB lui-même est cassé et qu’aucune option de boot n’est sélectionnable, on démarre depuis le média d’installation RHEL 10 et on utilise son mode Troubleshooting.

# Au menu de boot ISO, choisir :
Troubleshooting -> Rescue a Red Hat Enterprise Linux system

# L'installeur propose ensuite :
1) Continue (monte le système sous /mnt/sysimage)
2) Read-Only mount
3) Skip
# Choisir 1

# Une fois le système monté :
chroot /mnt/sysimage

L’option Continue détecte le système installé sur les disques, monte ses partitions sous /mnt/sysimage et propose un shell. Le chroot bascule l’environnement comme si l’on était démarré sur le système réel : commandes système locales, fichiers de configuration accessibles, possibilité d’utiliser dnf, passwd, grub2-install. C’est la voie de récupération la plus puissante, à utiliser quand toutes les autres ont échoué.

Étape 7 — Réparer un GRUB 2 cassé

Une réinstallation accidentelle d’un autre OS peut écraser GRUB. Depuis le chroot du mode rescue de l’ISO, deux commandes restaurent GRUB.

# Dans le chroot :
grub2-install /dev/sda                   # Pour BIOS legacy
# OU pour UEFI, le binaire EFI est déjà déposé par le paquet :
dnf reinstall -y grub2-efi-x64 shim-x64
grub2-mkconfig -o /boot/grub2/grub.cfg   # Régénère la conf GRUB
# Pour UEFI :
grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

La distinction BIOS / UEFI compte. En BIOS legacy, grub2-install écrit dans le secteur de boot du disque. En UEFI, le binaire EFI est livré par le paquet grub2-efi-x64 et déposé dans /boot/efi/EFI/redhat/ ; la réinstallation du paquet et la régénération du fichier grub.cfg suffisent. La commande efibootmgr -v liste les entrées EFI enregistrées dans le firmware ; en cas d’absence, efibootmgr --create en ajoute une.

Étape 8 — Diagnostiquer un service échoué au démarrage

Quand un service refuse de démarrer mais que le système boot quand même, le diagnostic se fait après reconnexion normale.

systemctl --failed
sudo journalctl -xeu nom.service
sudo systemctl status nom.service
sudo systemd-analyze verify /etc/systemd/system/nom.service

La sortie de --failed liste tout ce qui a échoué. Pour chaque entrée, journalctl -xeu nom montre le journal du service avec les explications du catalog systemd quand elles existent. systemd-analyze verify vérifie la syntaxe d’un fichier d’unité personnalisé — outil précieux pour les unités créées à la main.

Étape 9 — Boot lent et services bloquants

Un boot qui dépasse les 60 secondes a généralement un coupable identifiable. Trois commandes le pointent.

systemd-analyze
systemd-analyze blame | head -15
systemd-analyze critical-chain --fuzz=10s

systemd-analyze sans argument affiche le temps total du boot, scindé entre firmware, loader, kernel et userspace. blame liste les unités par durée individuelle. critical-chain montre la chaîne séquentielle qui a déterminé la durée totale — un service à 20 secondes hors chaîne critique n’a pas ralenti le boot ; le même à 20 secondes en chaîne critique l’a ralenti d’autant. La directive TimeoutStartSec dans une unité personnalisée évite qu’un script bloquant retarde tout le boot.

Étape 10 — Vérification post-réparation

sudo systemctl reboot
# Au retour :
systemctl is-system-running              # running, degraded ou autre
systemctl --failed
journalctl -p err -b
sestatus
df -h

systemctl is-system-running retourne running sur un système sain, degraded si une ou plusieurs unités sont en échec. La sortie degraded exige une investigation immédiate avec systemctl --failed. journalctl -p err -b liste les erreurs du boot courant, qu’aucun système en bonne santé ne devrait afficher au-delà d’éventuels avertissements matériels mineurs.

Erreurs fréquentes

Adaptation aux serveurs éloignés

Sur un serveur sans accès console physique, les techniques de récupération exigent une console série ou KVM IP fournie par l’hébergeur. La majorité des hébergeurs sérieux exposent une console KVM via leur panneau d’administration. Pour les VPS d’entrée de gamme sans cette option, le recours est généralement la commande rebuild from snapshot — d’où l’importance de prendre un snapshot juste avant toute modification risquée. Les sauvegardes hors site régulières restent l’assurance-vie qu’aucune procédure de rescue ne remplace.

Tutoriels frères

• Maîtriser systemd : units, timers et targets sur RHEL 10
• Gérer le stockage LVM et Stratis sur RHEL 10

Pour explorer plus loin

• 🔝 Retour à l’article principal : RHCSA EX200 v10 : la voie d’entrée Linux entreprise
• Documentation officielle : Web console (Cockpit) RHEL 10
• Manuel officiel GRUB 2

Questions fréquentes

Pourquoi enforcing=0 en plus de rd.break ?

SELinux empêche par défaut la modification de /etc/shadow en dehors d’un contexte autorisé. enforcing=0 bascule SELinux en permissive le temps de la session de récupération, ce qui autorise passwd à écrire. Sans ce paramètre, la commande passe mais le hash écrit a un mauvais contexte qui empêche le login ensuite.

Que faire si /.autorelabel ne déclenche pas le relabel ?

Vérifier que le fichier a été créé à la racine du système cible et non à la racine du shell initramfs. Si le système boot sans relabel, le créer manuellement depuis une session connectée et rebooter — le relabel se déclenchera au prochain démarrage.

La procédure rd.break fonctionne-t-elle sur tous les systèmes RHEL ?

Oui pour RHEL 7, 8, 9 et 10. Avant RHEL 7, les procédures différaient et ne sont plus pertinentes en pratique sur les systèmes en exploitation actuelle.

Comment empêcher l’édition GRUB par un attaquant qui a accès physique ?

Définir un mot de passe GRUB avec grub2-setpassword exige une authentification avant toute édition de menu ou ajout de paramètre. Cette protection est complémentaire d’une politique de sécurité physique, pas un substitut.

Que faire si même le mode rescue de l’ISO ne reconnaît pas le disque ?

Vérifier que le mode SATA/AHCI du BIOS n’a pas été modifié depuis l’installation. Pour les configurations RAID matériel, charger le pilote spécifique au démarrage de l’ISO via le menu d’options avancées.

Comment créer un point de reprise rapide ?

Avant toute opération risquée, prendre un snapshot LVM du LV racine. La commande lvcreate -L 2G -s -n root_snap /dev/vg/root capture l’état actuel ; en cas de problème, lvconvert --merge /dev/vg/root_snap au prochain reboot rétablit l’état d’avant.