Linux bloqué en mode emergency : corriger une erreur dans fstab

Partir du message affiché

Sur une machine qui utilise systemd, l’écran d’urgence mentionne souvent un échec de dépendance ou une unité se terminant par .mount. Notez son nom et le chemin évoqué avant de saisir quoi que ce soit. Un montage destiné à /mnt/archives devient généralement une unité semblable à mnt-archives.mount : cette correspondance aide à remonter de l’erreur jusqu’à la ligne de configuration.

Après avoir ouvert la console de secours avec le mot de passe administrateur si la distribution le demande, affichez les unités en échec. --type=mount limite le bruit aux montages, tandis que --no-pager évite de rester bloqué dans le paginateur.

systemctl --failed --type=mount --no-pager

Demandez ensuite l’état détaillé de l’unité réellement citée à l’écran. Remplacez le nom d’exemple ci-dessous par celui que vous venez de relever.

systemctl status mnt-archives.mount --no-pager
journalctl -b -u mnt-archives.mount --no-pager

Le premier affichage donne la raison immédiate de l’échec. Le second restreint le journal au démarrage en cours et à cette unité. Si le nom du montage n’est pas encore évident, les erreurs prioritaires du démarrage courant offrent une vue plus large.

journalctl -b -p err --no-pager

Cherchez une formulation liée à un périphérique introuvable, un UUID, un type de système de fichiers, une option inconnue ou un point de montage. Ne prenez pas chaque ligne rouge pour la cause : certaines erreurs sont une conséquence du montage manquant. C’est l’unité .mount et le chemin qu’elle vise qui servent de fil conducteur.

Relire fstab sans toucher au reste

/etc/fstab décrit les systèmes de fichiers que la machine sait monter. Chaque ligne active associe notamment une source, un point de montage, un type et des options. Les lignes vides et celles qui commencent par # sont ignorées. Commencez donc par lire le fichier, avec des numéros de ligne si l’outil est disponible, sans l’ouvrir tout de suite dans un éditeur.

nl -ba /etc/fstab

Si nl n’existe pas dans la console réduite, cat /etc/fstab suffit. Repérez la ligne dont le point de montage correspond à l’unité fautive ou celle qui référence l’UUID signalé dans le journal. Ne commentez pas toutes les lignes « pour voir » : la racine, /boot, /home ou un volume applicatif peuvent être nécessaires au système.

Une entrée habituelle comporte six champs séparés par des espaces ou des tabulations. Un chemin contenant un espace doit employer l’échappement prévu par fstab, par exemple \040, même s’il semble entouré de guillemets. Une colonne manquante, une option placée dans la mauvaise colonne ou une faute de frappe peut suffire à rendre la ligne inutilisable.

Comparer l’entrée avec les volumes réellement présents

La vue la plus lisible est généralement fournie par lsblk -f. Elle rassemble les périphériques bloc détectés, leur type de système de fichiers, leur étiquette, leur UUID et leurs points de montage. blkid lit directement les métadonnées reconnues des volumes et complète utilement cette vue ; dans une console de secours, vous êtes normalement déjà administrateur.

lsblk -f
blkid

Comparez caractère par caractère l’identifiant de la ligne suspecte avec les UUID affichés. Les noms tels que /dev/sdb1 peuvent changer selon l’ordre de détection des disques, raison pour laquelle UUID= est généralement préférable. Un UUID ne correspondant à aucun volume présent conduit à deux diagnostics différents : soit l’identifiant de fstab est erroné alors que le bon volume apparaît sous un autre UUID, soit le disque attendu n’est pas détecté du tout.

Quand le disque est là, mais pas sous le bon UUID

Vérifiez d’abord que le volume identifié est bien celui attendu grâce à sa taille, son type et, si elle existe, son étiquette. Si cette concordance est claire, la correction consiste à remplacer uniquement l’UUID fautif par celui affiché par lsblk -f ou blkid. Ne recopiez pas l’UUID d’un volume qui « a la bonne taille » sans autre confirmation : monter la mauvaise partition sur /home ou un répertoire de données peut masquer temporairement le contenu déjà présent sous ce chemin.

Quand le disque n’apparaît nulle part

Dans ce cas, modifier l’UUID ne fera pas revenir le matériel. Si le volume est essentiel, arrêtez le diagnostic logiciel et contrôlez plutôt sa présence, sa connexion, son alimentation, le déverrouillage éventuel de son conteneur chiffré ou la disponibilité du stockage réseau. S’il s’agit d’un disque USB ou d’un partage facultatif, commenter temporairement sa seule ligne permet de démarrer sans prétendre avoir réparé la cause matérielle.

Quand la source existe mais que le montage échoue encore

Contrôlez le point de montage avec la commande suivante, en remplaçant le chemin. Un chemin absent, mal orthographié, transformé en fichier ordinaire ou inaccessible à cause d’un parent incorrect n’est pas le même problème qu’un UUID invalide.

ls -ld /mnt/archives

systemd peut créer le répertoire cible d’une unité de montage lorsqu’il la lance, tandis que des outils ou environnements plus minimaux peuvent exiger qu’il existe déjà. Si le chemin prévu est faux, corrigez-le dans la ligne. S’il est exact mais absent, ne créez le répertoire qu’après avoir confirmé que cet emplacement est bien voulu. Enfin, si le journal cite une option inconnue, consultez man mount et la page de manuel du système de fichiers concerné depuis un environnement complet : les options ne sont pas universelles entre ext4, XFS, Btrfs, NFS ou CIFS.

Rendre la correction possible sans perdre l’original

Une console d’urgence peut présenter la racine en lecture seule. Vérifiez son montage avant d’essayer d’enregistrer fstab. Cette commande est uniquement descriptive.

findmnt -no TARGET,OPTIONS /

Si les options contiennent ro, il faut rendre la racine modifiable le temps de la correction. La commande suivante modifie l’état du montage : utilisez-la seulement après avoir vérifié que / est bien la racine du système installé dans cette console.

mount -o remount,rw /

Dans certains initramfs, la vraie racine est montée sous /sysroot, /root ou un chemin propre à la distribution. Ne remplacez pas mécaniquement / par l’un de ces chemins : examinez d’abord les montages avec findmnt ou mount, puis suivez la procédure de secours de votre distribution. Si la racine refuse un remontage en écriture avec une erreur d’entrée-sortie ou une erreur propre au système de fichiers, n’insistez pas et ne lancez pas fsck au hasard ; ce symptôme dépasse une simple faute dans fstab.

Une fois l’écriture possible, conservez exactement le fichier actuel avant de l’éditer. Vérifiez d’abord qu’un fichier portant le nom de sauvegarde choisi n’existe pas déjà, puis copiez fstab en préservant ses attributs.

ls -l /etc/fstab /etc/fstab.before-fix
cp -a /etc/fstab /etc/fstab.before-fix

Si la première commande montre déjà /etc/fstab.before-fix, choisissez un autre nom au lieu de l’écraser. Cette copie reste sur la même machine : elle protège contre une mauvaise édition, mais ne remplace évidemment pas une sauvegarde externe.

Corriger uniquement l’entrée fautive

Ouvrez maintenant le fichier avec l’éditeur disponible dans l’environnement, par exemple vi ou nano. Il n’est pas nécessaire de réécrire le fichier ni d’en changer les permissions.

vi /etc/fstab

Si le bon volume est présent, remplacez uniquement l’UUID, le point de montage, le type ou l’option que le diagnostic a démontré faux. Conservez les autres champs. Si le disque est absent et non indispensable au démarrage, placez un # au début de cette seule ligne. Ce commentaire constitue une neutralisation temporaire et facilement réversible : il faudra revenir au fichier lorsque le support sera de nouveau disponible.

Pour un support réellement facultatif sur une machine systemd, une ligne peut associer nofail à un délai d’attente borné tel que x-systemd.device-timeout=10s. Le délai indique combien de temps systemd attend l’apparition du périphérique ; il ne corrige ni un UUID faux ni un disque en panne, et cette option x-systemd.* n’est pas portable vers les systèmes sans systemd.

Une option invalide doit être retirée ou corrigée d’après la documentation du type de système de fichiers, pas remplacée par une collection d’options trouvées au hasard. De même, ne changez pas globalement les permissions de /etc ou du point de montage. Une panne de montage ne justifie ni formatage, ni suppression d’une base système, ni réparation destructive.

Valider avant de rendre la main au démarrage

Enregistrez le fichier, puis demandez à util-linux d’en vérifier la lisibilité et l’utilisabilité. Cette vérification est le premier choix recommandé par la page de manuel de mount pour contrôler fstab.

findmnt --verify --verbose

Si une erreur demeure, revenez à la ligne qu’elle désigne. Ne redémarrez pas en espérant qu’elle disparaisse. findmnt --verify repère de nombreux problèmes de syntaxe et de cohérence, mais il ne peut pas garantir qu’un serveur réseau répondra ni que chaque pilote acceptera toutes ses options au moment du montage.

Sur systemd, rechargez ensuite la configuration. Cette commande relance les générateurs, dont celui qui transforme les entrées de fstab en unités de montage.

systemctl daemon-reload

Si vous voulez éprouver seulement l’entrée corrigée, demandez le montage par son point cible. La commande suivante modifie les montages actifs : remplacez le chemin et ne l’exécutez que si monter ce volume maintenant est sans danger.

mount /mnt/archives

mount -a est parfois proposé comme test global, mais il tente réellement de monter toutes les entrées éligibles de fstab, à l’exception notamment de celles marquées noauto. Il peut donc contacter des partages réseau, solliciter des supports lents ou déclencher un autre montage que celui que vous venez de corriger. La page de manuel recommande findmnt --verify pour la vérification de fstab. N’utilisez mount -a qu’après cette vérification, si vous avez relu toutes les entrées concernées et acceptez ces effets.

mount -a

Sur une machine systemd, contrôlez enfin que l’unité visée ne signale plus le même échec. Si vous l’avez laissée commentée parce que son disque est absent, il est normal qu’elle ne soit plus générée après le rechargement.

systemctl --failed --type=mount --no-pager

Lorsque le contrôle est propre, systemctl default demande à systemd de rejoindre la cible de démarrage habituelle. Dans de nombreux écrans d’urgence, exit ou Ctrl+D laisse également le processus de démarrage reprendre. Si l’environnement ne sait pas continuer proprement, un redémarrage contrôlé reste possible après validation et synchronisation des écritures.

systemctl default

Si vous devez redémarrer à la place, utilisez la commande prévue par votre environnement, par exemple systemctl reboot sur systemd. Évitez une coupure électrique : même si la modification est petite, le système peut encore avoir des écritures en attente.

Quand la console de secours ne ressemble pas à ce guide

Le mot « emergency » recouvre plusieurs contextes. Le mode d’urgence de systemd, lancé depuis le système installé, fournit normalement systemctl, les unités .mount et parfois le journal du démarrage. Un initramfs intervient plus tôt : il peut utiliser BusyBox ou dracut, monter la future racine ailleurs et ne proposer qu’un petit ensemble de commandes. Un système sans systemd emploiera son propre mécanisme d’initialisation et ses propres journaux.

Les principes restent les mêmes : identifier le message de montage, localiser le véritable /etc/fstab du système installé, vérifier la racine avant de la rendre modifiable, comparer les identifiants aux périphériques détectés, sauvegarder, puis ne changer qu’une entrée. En revanche, les chemins et la manière de reprendre le boot doivent suivre la documentation de la distribution ou de l’environnement de secours effectivement affiché.

Si l’échec concerne la racine elle-même avant qu’elle ne soit montée, si aucun volume attendu n’apparaît, si le noyau rapporte des erreurs d’entrée-sortie ou si un conteneur chiffré ne s’ouvre pas, arrêtez-vous à ce constat. Ce guide traite une configuration de montage fautive ; il ne transforme pas une panne matérielle ou une corruption en simple erreur de texte.

Une correction étroite vaut mieux qu’une réparation spectaculaire

Sortir du mode emergency après une erreur de fstab demande surtout de résister aux gestes trop larges. Le journal désigne le montage, lsblk et blkid disent ce que la machine voit, puis la copie de sauvegarde autorise une correction mesurée. Une fois findmnt --verify satisfait et la configuration systemd rechargée, le démarrage peut reprendre sans que les données aient été déplacées ni réécrites.

Après le retour au système normal, rétablissez proprement toute ligne temporairement commentée lorsque le support revient, puis refaites les mêmes contrôles. Si vous avez choisi nofail, vérifiez aussi le comportement des applications quand le volume manque : un démarrage réussi n’est pas une preuve que leurs données se trouvent au bon endroit.