Comment corriger une erreur de démarrage /etc/fstab avec journalctl

Niveau : Débutant / Intermédiaire
Durée estimée : ~15 minutes
Objectif : Analyser les journaux système avec journalctl pour identifier et corriger une erreur dans /etc/fstab qui empêche le démarrage du système.

Introduction

Une simple erreur de syntaxe dans /etc/fstab peut empêcher un serveur de démarrer et vous laisser dans un shell de maintenance d'urgence. La récupération exige d'analyser les journaux système pour localiser précisément le point de défaillance. Dans ce tutoriel, nous utiliserons journalctl pour interroger le journal de systemd et afficher les journaux système que Linux génère au démarrage. Comprendre les journaux systemd est une compétence essentielle de la gestion des journaux sous Linux, qui garantit une récupération rapide et une haute disponibilité de vos services. Une connaissance de base des commandes journalctl est nécessaire pour repérer le point de montage à l'origine de la panne.

Gestion des journaux sous Linux et pile de journalisation

Avant de passer à la récupération, il est important de comprendre les composants impliqués. Systemd (le système d'initialisation et gestionnaire de services de Linux) utilise Systemd-journald (le service système qui collecte et stocke les données de journalisation). Ce service rassemble chaque journal (log) (un enregistrement des événements qui se produisent dans le système) dans le Journal (les données de journalisation au format binaire stockées par Systemd-journald). Cela comprend les journaux système (enregistrements des événements et changements d'état à l'échelle du système), les journaux de démarrage (enregistrements du processus de démarrage du système) et les journaux du noyau (messages générés par le noyau du système d'exploitation).

Selon votre configuration, il peut s'agir de journaux volatils (journaux conservés en mémoire et perdus au redémarrage) ou de journaux persistants (journaux qui survivent aux redémarrages, généralement stockés sur disque). Le journal grossit continuellement, c'est pourquoi la rotation des journaux (le processus d'archivage et de gestion des anciens fichiers journaux afin d'économiser de l'espace disque) est gérée automatiquement par systemd.

Prérequis

Avant de commencer, assurez-vous que les conditions suivantes sont remplies :

• Système d'exploitation : Testé sur Ubuntu 22.04/24.04 LTS, Debian 12/13, AlmaLinux/Rocky 9/10
• Accès : Accès direct à la console (IPMI, VNC ou console physique) pour atteindre le shell d'urgence
• Connaissances requises : Maîtrise de la ligne de commande Linux et édition de texte de base

Étape 1 : Identifier l'échec du démarrage

Une erreur de syntaxe, une faute de frappe ou un périphérique manquant dans /etc/fstab déclenche le mode d'urgence, interrompt le processus de démarrage et affiche un message du type :

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or "exit" to boot into default mode.
Give root password for maintenance
(or press Control-D to continue):

Saisissez votre mot de passe root pour accéder à l'invite de commandes. À ce stade, certains systèmes de fichiers peuvent ne pas être montés ou être montés en lecture seule.

Étape 2 : Utiliser journalctl pour afficher et analyser les journaux système générés par Linux

Pour identifier la cause de la panne, nous devons consulter les journaux du démarrage en cours.

Exécutez la commande suivante :

sudo journalctl -xb

Nous utilisons ici Journalctl (un utilitaire en ligne de commande permettant d'interroger le journal de systemd). C'est l'une des commandes journalctl les plus essentielles. Elle demande à l'outil d'afficher les journaux du démarrage en cours (-b) et d'inclure des textes explicatifs supplémentaires (-x).

Cette sortie peut être volumineuse. Nous devons effectuer un filtrage des journaux (le processus consistant à restreindre la sortie des journaux selon des critères précis) pour trouver l'erreur.

Pour effectuer une recherche dans le paginateur (qui utilise less), saisissez /fstab ou /mount puis appuyez sur Entrée.

Extrait de la sortie attendue :

-- Subject: A start job for unit mnt-data.mount has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
--
-- A start job for unit mnt-data.mount has finished with a failure.
--
-- The job identifier is 123 and the job result is failed.

Cela indique qu'une unité (unit) (un fichier de configuration qui décrit comment gérer une ressource dans systemd) chargée de monter /mnt/data a échoué. Plus précisément, l'unité de montage (mount unit) (un fichier de configuration d'unité qui contient les informations sur un processus géré par systemd) n'a pas pu démarrer.

Étape 3 : Filtrer les journaux systemd pour trouver des erreurs précises

Si faire défiler tout le journal de démarrage est trop lent, nous pouvons analyser les journaux avec journalctl en appliquant des filtres spécifiques.

Exécutez la commande suivante pour n'afficher que les erreurs de haute priorité :

sudo journalctl -p err -b

Sortie attendue :

May 23 10:00:01 server systemd[1]: Failed to mount mnt-data.mount - /mnt/data.
May 23 10:00:01 server systemd[1]: Dependency failed for Local File Systems.

Grâce au filtrage des journaux avec journalctl par priorité (-p err), nous éliminons les messages purement informatifs.

Nous pouvons aussi consulter directement les journaux d'un service si nous connaissons l'unité exacte qui a échoué. Exécutez :

sudo journalctl -u mnt-data.mount

Lorsque vous analysez les journaux avec journalctl au niveau de l'unité, vous isolez précisément le problème de configuration. Une autre méthode de filtrage avec journalctl consiste à spécifier une plage horaire, mais pour les problèmes de démarrage, le filtrage par unité est l'approche la plus efficace.

Étape 4 : Corriger l'erreur dans /etc/fstab

Maintenant que le journal de systemd a confirmé que le problème vient du point de montage /mnt/data, nous devons corriger le fichier de configuration.

Tout d'abord, essayez de modifier le fichier. Si vous obtenez l'erreur Read-only file system à l'enregistrement, vous devez remonter le système de fichiers racine en lecture-écriture, car le mode d'urgence le monte souvent en lecture seule :

sudo mount -o remount,rw /

Ensuite, sauvegardez le fichier de configuration avant d'y apporter des modifications :

sudo cp /etc/fstab /etc/fstab.bak

Puis ouvrez le fichier (sur les systèmes basés sur RPM comme AlmaLinux, Rocky ou RHEL, nano n'est pas forcément installé par défaut ; installez-le d'abord avec sudo dnf install -y nano) :

sudo nano /etc/fstab

Repérez la ligne qui référence /mnt/data (vous pouvez obtenir l'UUID correct avec blkid) :

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defualts 0 2

Remarquez la faute de frappe : defualts au lieu de defaults. Corrigez la faute :

UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data ext4 defaults 0 2

Enregistrez le fichier et quittez l'éditeur. Rechargez ensuite la configuration du gestionnaire systemd afin que systemd prenne en compte les modifications apportées à /etc/fstab :

sudo systemctl daemon-reload

Vérification

Avant de redémarrer, vérifiez la syntaxe de votre /etc/fstab avec findmnt :

findmnt --verify

Si aucune erreur n'est signalée, vérifiez ensuite que le point de montage fonctionne :

Exécutez :

sudo mount -a

Si la commande n'affiche aucune sortie, la syntaxe est correcte et le montage a réussi. Si une erreur persiste, la commande affichera un message d'erreur. Sur Debian 13 et AlmaLinux 10, le message peut préciser la raison exacte (p. ex. Unknown parameter 'defualts'), mais sur Ubuntu 24.04, la sortie est souvent générique (wrong fs type, bad option). Sur Ubuntu, exécutez sudo dmesg | tail pour obtenir des détails.

Une fois la vérification effectuée, quittez le shell d'urgence pour poursuivre le démarrage ou redémarrez le système :

sudo systemctl reboot

Après le redémarrage, vous pouvez consulter à nouveau les journaux du service avec les commandes journalctl pour vous assurer que le montage s'est déroulé correctement lors du démarrage normal :

sudo journalctl -u mnt-data.mount -b

Dépannage

• Le shell d'urgence est inaccessible : Si le compte root est verrouillé et que vous ne pouvez pas accéder au shell d'urgence, vous devez démarrer le serveur à l'aide d'une clé Live USB ou d'un environnement de récupération, monter la partition racine et modifier /etc/fstab directement à partir de là.
• L'UUID a changé : Si vous avez formaté une partition ou remplacé un disque, l'UUID change. Utilisez sudo blkid pour trouver le nouvel UUID et mettez à jour /etc/fstab en conséquence.
• Éviter les échecs de démarrage pour les disques non essentiels : Pour les volumes qui ne sont ni la racine ni des volumes système (comme les disques de sauvegarde ou de données), ajoutez l'option de montage nofail à l'entrée de /etc/fstab (p. ex. ext4 defaults,nofail 0 2). Cela indique à systemd de poursuivre le démarrage même si le périphérique ne parvient pas à se monter.

Annulation

Si le serveur a démarré correctement mais que la ligne /mnt/data modifiée provoque un comportement inattendu des applications, vous pouvez annuler le montage en commentant la ligne dans /etc/fstab :

sudo sed -i 's|^UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|#UUID=1234abcd-56ef-78gh-90ij-klmnopqrstuv /mnt/data|' /etc/fstab

Démontez ensuite le volume pour restaurer l'état précédent :

sudo umount /mnt/data

Conclusion

Une gestion des journaux sous Linux efficace repose en grande partie sur la capacité à naviguer dans les journaux systemd. Avec journalctl, vous pouvez afficher les journaux système que Linux génère afin de les analyser efficacement et de vous remettre de pannes de démarrage critiques, comme les erreurs de configuration de /etc/fstab. Maîtriser ces outils vous permet de maintenir la disponibilité et de diagnostiquer des problèmes complexes sur l'ensemble de votre infrastructure.

Version du document : 1.0
Dernière mise à jour : mai 2026
Responsable : Équipe de documentation technique