Rédigé par Rédaction CyberSDF / 19 September 2026

fstab et erreur d’UUID : réparer un démarrage bloqué en mode urgence

Une entrée d’/etc/fstab qui réclame un UUID disparu suffit à interrompre le démarrage : systemd monte les systèmes de fichiers avant les services, l’unité de montage échoue, et la machine s’arrête sur un shell d’urgence au lieu du gestionnaire de session. Le cas arrive après le clonage d’un disque, la recréation d’une partition ou le retrait d’un support externe resté déclaré. La machine reste utilisable, le réseau n’est pas nécessaire et aucun support d’installation n’est requis, tout se répare depuis l’invite d’urgence en six commandes contrôlables, de systemctl –failed à systemctl default. Les autres erreurs de montage dans fstab se réparent de la même façon, recensées dans les guides Linux, et la marche à suivre tient dans deux fichiers d’unités du dépôt systemd : /etc/fstab converti en unité .mount, puis local-fs.target qui déclenche l’urgence.

Dependency failed for Local File Systems vient de local-fs.target, pas de la ligne fautive

Le message Dependency failed for Local File Systems n’accuse pas le disque, il signale que la cible local-fs.target n’a pas été atteinte. La page systemd.mount(5) publiée par Debian décrit la conversion : chaque ligne d’/etc/fstab devient une unité .mount au démarrage et au rechargement de la configuration, et une entrée sans nofail crée une dépendance de type Requires vers local-fs.target. Le fichier d’unité local-fs.target du dépôt systemd porte OnFailure=emergency.target, avec OnFailureJobMode=replace-irreversibly. Un montage exigé qui échoue fait donc tomber la cible, et la cible tombée appelle emergency.target, que systemd.special(7) présente comme le mode minimal ne lançant aucun autre service ni aucun autre montage. Le nom de l’unité suit le point de montage, /mnt/data donnant mnt-data.mount, et systemctl accepte le chemin brut puisque la page systemctl(1) documente l’équivalence entre systemctl status /mnt/data et systemctl status mnt-data.mount.

[FAILED] Failed to mount /mnt/data.
See 'systemctl status mnt-data.mount' for details.
[DEPEND] Dependency failed for Local File Systems.
You are in 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.

Deux de ces phrases sortent du code du projet : src/core/mount.c porte le gabarit Failed to mount %s. et src/core/job.c le gabarit Dependency failed for %s. La bannière appartient à systemd-sulogin-shell, qui l’écrit avant de lancer sulogin.

Local File Systems est la description portée par le fichier d’unité local-fs.target. Ces sorties ont été relevées sur Debian 12 bookworm, dont systemd porte la version 252.36-1~deb12u1.

Procédure en six étapes pour repartir du shell d’urgence

Six gestes suffisent, dans cet ordre : constater l’unité en échec, lire le motif dans le journal, vérifier l’état de la racine, relever l’UUID réel, corriger la ligne, puis remonter le point de montage et rendre la main au démarrage. L’exemple reste /mnt/data sur une Debian 12, le nom d’unité se déduisant toujours du chemin. Trois détails séparent une réparation qui tient d’une qui échoue au redémarrage suivant : /etc/fstab n’est relu par le générateur qu’au rechargement du démon, une racine montée en lecture seule refuse toute écriture dans /etc, et une unité laissée en échec ne se relance pas toujours d’elle-même. Aucune commande ne touche au noyau ni au chargeur d’amorçage, tout se joue dans le fichier et dans l’état des unités. Chaque étape se termine par ce que l’écran doit afficher.

1. Lister les unités en échec, l’option –failed équivalant à –state=failed.

   systemctl --failed
   

   Ce que vous devez voir : une ligne ● mnt-data.mount loaded failed failed /mnt/data, les colonnes failed désignant l’unité fautive. La description reprend le point de montage.

2. Lire le motif exact, systemctl status acceptant le chemin.

   systemctl status /mnt/data
   journalctl -xb -u mnt-data.mount --no-pager
   

   Ce que vous devez voir : un bloc Active: failed suivi des lignes de l’unité, dont l’erreur renvoyée par mount(8). La bannière conseille elle-même journalctl -xb.

3. Contrôler l’état de la racine avant d’écrire, findmnt -n -o OPTIONS / sortant les options.

   findmnt -n -o OPTIONS /
   mount -o remount,rw /
   findmnt -n -o OPTIONS /
   

   Ce que vous devez voir : une sortie qui commence par ro ou par rw, puis une ligne qui commence par rw après la remontée. Sur une racine en lecture seule, aucune écriture dans /etc ne passe.

4. Relever l’UUID réel, puis relire la ligne écrite.

   blkid
   grep -n "UUID=" /etc/fstab
   

   Ce que vous devez voir : une ligne par périphérique sous blkid, l’UUID entre guillemets, et la même chaîne dans la ligne correspondante d’/etc/fstab, sans les guillemets que le wiki Arch dit de retirer. La casse compte : fstab(5) rappelle que l’UUID s’écrit en minuscules sauf sur un volume FAT ou NTFS. Une partition ajoutée après coup s’ajoute pareillement, comme dans créer une partition home dédiée.

5. Corriger l’entrée, puis faire relire le fichier. La seconde commande désactive la ligne, un dièse en tête valant commentaire pour fstab(5).

   sed -i "s/UUID=ancien-uuid/UUID=nouvel-uuid/" /etc/fstab
   sed -i "s/^UUID=ancien-uuid/#UUID=ancien-uuid/" /etc/fstab
   grep -n "UUID=" /etc/fstab
   findmnt --verify --verbose
   systemctl daemon-reload
   

   Ce que vous devez voir : la ligne corrigée dans la sortie de grep, aucune erreur signalée par findmnt --verify, puis plus rien au rechargement. fstab(5) recommande ce systemctl daemon-reload après chaque modification, et systemd.mount(5) confirme que les unités ne sont régénérées qu’à ce moment-là.

6. Remonter le point de montage, effacer l’échec, rendre la main au démarrage.

   systemctl start mnt-data.mount
   systemctl is-active mnt-data.mount
   systemctl reset-failed mnt-data.mount
   systemctl default
   

   Ce que vous devez voir : active en réponse à is-active, puis la reprise du démarrage et l’invite de connexion. Taper exit produit le même effet, et un start qui échoue renvoie à l’étape 2.

nofail et x-systemd.device-timeout : 90 secondes par défaut, 5 secondes sur demande

Désactiver une entrée au lieu de la réparer repose sur deux options, et l’écart entre elles se compte en minutes. Le wiki Arch chiffre le délai d’attente du périphérique à 90 secondes par défaut, y compris pour une entrée marquée nofail, ce qui explique un démarrage qui semble figé avant de reprendre. La page systemd.mount(5) livrée avec Debian 12 détaille l’effet de nofail : le montage devient seulement souhaité par local-fs.target au lieu d’être exigé, et l’unité n’est plus ordonnée avant la cible, si bien que le démarrage se poursuit même si le point de montage ne peut pas être monté. Ajouter x-systemd.device-timeout=5s ramène l’attente à cinq secondes. La même page prévient que cette option n’est lue que dans /etc/fstab : écrite dans le champ Options= d’un fichier d’unité, elle est ignorée.

La troisième ligne convient à un disque amovible branché une fois sur deux. Sur un volume dont un service a besoin, nofail déplace la panne : le démarrage passe, puis le service échoue plus tard.

Pour une très grande partition, le wiki Arch décrit une autre voie, x-systemd.automount : contrôle et montage sont reportés à la première lecture. Le même article signale que le type devient autofs, que l’outil locate ignore par défaut. Un délai de 0 rend l’attente infinie.

Le mode urgence ne garantit pas une racine en lecture seule

Le conseil qui circule veut qu’on remonte la racine en écriture dès l’arrivée en mode urgence, or systemd.special(7) écrit le contraire d’une règle fixe : selon le chemin emprunté, la racine peut être montée en lecture seule ou en lecture-écriture, et rien n’est remonté spécialement pour cette cible. Deux cas cités par la page, un démarrage avec ro sur la ligne de commande du noyau laisse la racine en lecture seule, tandis qu’un système déjà partiellement démarré, dont les disques ont été remontés en écriture, arrive en urgence avec une racine accessible. La vérification tient en une commande, findmnt -n -o OPTIONS /, et le remontage ne se justifie que si la réponse commence par ro. Ailleurs, mount -o remount,rw / réussit sans rien changer, ce qui n’est pas une raison pour le lancer à l’aveugle.

La sortie du shell réserve le même écart avec la marche à suivre habituelle. systemd-sulogin-shell affiche la bannière, lance sulogin, puis, quand la session se termine, recharge la configuration du gestionnaire avant de démarrer default.target, comme le montre la fonction main de son code source en version 252. Le daemon-reload manuel garde son intérêt pour tester le montage avant de quitter.

Les deux pages de manuel ne décrivent pas le même lecteur. fstab(5) est une page util-linux et prévient que systemd applique ses propres règles, avec des différences assumées. La ligne d’un même fichier se lit donc dans la documentation systemd quand la machine démarre avec systemd, comme sur Debian 12. Ces unités et leurs journaux sont décrits dans unités systemd et leur journal.

Cinq questions qui décident entre réparer la ligne et désactiver le montage

Sources

• systemd.mount(5), page de manuel publiée par Debian, systemd 252.36-1~deb12u1
• fstab(5), page de manuel util-linux
• fstab, wiki Arch Linux
• local-fs.target, fichier d’unité du dépôt systemd, version 252