Debian 13 : erreur dans fstab empêche le démarrage — solution la plus rapide en mode rescue

Ce qui casse réellement quand /etc/fstab empêche le démarrage

/etc/fstab est trompeusement simple : un seul fichier qui associe « quoi monter » à « où et comment ». Une petite erreur peut bloquer le démarrage parce que la chaîne de démarrage suppose que les systèmes de fichiers principaux sont montés correctement.

Ce que Debian 13 fait en coulisses

Debian 13 démarre avec systemd qui orchestre des unités de montage dérivées de fstab. Ces montages participent à des targets comme local-fs.target (systèmes de fichiers locaux montés) et multi-user.target (services normaux). Si un montage requis échoue, systemd peut :

• vous laisser en mode emergency (shell root, services minimaux),
• ou en mode rescue (un peu plus de services),
• ou rester bloqué en attendant un périphérique qui n’apparaît jamais, selon des options comme nofail, x-systemd.device-timeout=, et si le montage est marqué comme requis.

En pratique, les modes d’échec se regroupent autour de quelques causes :

• Incohérence d’identifiant : UUID/LABEL/PARTUUID incorrect, renommage du périphérique, disque remplacé ou cloné.
• Mauvais point de montage : faute de frappe dans le répertoire de montage, type de système de fichiers erroné, répertoire manquant.
• Chaîne de dépendance : un montage est requis par un autre montage (par ex. /var nécessaire avant des services), ou par des unités systemd qui supposent sa présence.
• Problèmes de système de fichiers : journal propre, superbloc corrompu, ou un arrêt non propre qui impose un montage strict.
• Montage réseau surprise : entrée NFS/CIFS sans _netdev / dépendances réseau systemd appropriées, bloquant le démarrage tôt.

Point opérationnel clé : ne « corrigez » pas fstab en devinant. Collectez des preuves. Confirmez les identifiants. Confirmez le type de système de fichiers. Confirmez la vue de systemd sur l’échec. Puis éditez une seule fois.

Une petite blague pour déstresser : /etc/fstab est le seul fichier où un espace manquant peut mettre hors ligne un serveur entier et donner l’impression d’être personnellement offensé.

Mode d’analyse rapide (vérifier premier/deuxième/troisième)

Voici la séquence « j’ai cinq minutes avant qu’on déclare un incident ». Elle est optimisée pour la vitesse et le signal élevé.

Premier : identifier le montage exact en échec et pourquoi systemd s’en préoccupe

• Sur le shell d’urgence du système cassé, trouvez les unités échouées : systemctl --failed.
• Examinez les logs de l’unité de montage : journalctl -xb et cherchez « mount » / « Dependency failed » / « timed out ».
• Décidez : est-ce un montage local requis (bloque le démarrage) ou un montage optionnel (devrait être nofail) ?

Second : vérifier l’identité du périphérique, pas son nom

• Listez les blocs avec UUID et types : lsblk -f et blkid.
• Décidez : est-ce que fstab référence un UUID qui n’existe pas ? Si oui, corrigez avec le bon UUID ou utilisez LABEL si vous contrôlez les labels.

Troisième : déterminer si le système de fichiers est montable ou nécessite une réparation

• Essayez de monter en lecture seule en rescue pour tester : mount -o ro.
• Si cela échoue avec corruption ou erreurs de journal : lancez le fsck approprié pour ext*, ou vérifiez les outils xfs/btrfs (xfs utilise xfs_repair).
• Décidez : pouvez-vous monter en lecture seule et corriger la config, ou avez-vous besoin d’une réparation avant toute chose ?

Quatrième (seulement si nécessaire) : contourner pour démarrer et corriger depuis un vrai userspace

• Ajoutez temporairement nofail et un timeout court pour les montages non critiques.
• Ou commentez la ligne problématique pour atteindre le mode multi-user, puis corrigez proprement avec les outils complets.
• Décidez : avez-vous besoin du montage pour que le système soit fonctionnel, ou avez-vous besoin que l’hôte soit en ligne d’abord ?

Faits intéressants et contexte historique (parce que ça aide)

Comprendre pourquoi les choses sont ainsi accélère le débogage. Voici quelques éléments concrets qui comptent quand vous êtes immergé dans un shell de secours.

1. fstab est antérieur à Linux. L’idée d’une table statique de systèmes de fichiers vient de l’Unix traditionnel, bien avant que le stockage hotplugged soit la norme.
2. Les noms de périphériques ne sont pas stables. /dev/sda peut devenir /dev/sdb après des changements de contrôleur ; les UUID existent en grande partie parce que les admins en ont eu marre de ce jeu.
3. systemd transforme les lignes fstab en unités. Chaque entrée devient une unité .mount, participant à un graphe de dépendances. Un seul montage échoué peut bloquer des targets.
4. nofail a changé la culture. Les anciens scripts de démarrage continuaient souvent ; systemd est plus strict par défaut à moins qu’on lui dise le contraire.
5. initramfs est un petit OS. Quand vous tombez dans initramfs, vous êtes dans un environnement minimal où certains outils peuvent manquer, et les pilotes sont limités à ce qui a été inclus.
6. Les UUID vivent dans les métadonnées du système de fichiers. Cloner des disques peut dupliquer des UUID, créant des montages « corrects en apparence » mais faux si les deux existent.
7. Les montages réseau étaient gérés tard. La parallélisation du démarrage moderne implique que les entrées NFS/CIFS dans fstab ont besoin de dépendances réseau explicites ou elles se concurrencent avec le réseau.
8. /etc/fstab reste pertinent malgré l’automontage. Même avec udev et des automounts de bureau, les serveurs comptent sur des montages prévisibles au démarrage pour les services et les logs.
9. Les options de montage sont une politique opérationnelle. Des éléments comme errors=remount-ro, noatime, et les timeouts systemd concernent davantage la fiabilité que la micro-performance.

Une citation, et je reste bref. Paraphrasant Gene Kim : La fiabilité vient de la conception de systèmes qui échouent de manière prévisible et récupérable, pas des performances héroïques.

La réparation la plus rapide en mode rescue (pas à pas, avec décisions)

L’objectif est d’éditer le vrai /etc/fstab, pas celui de l’environnement de secours. Ça paraît évident jusqu’à ce que vous ayez édité le mauvais fichier et que vous vous demandiez pourquoi rien n’a changé.

Étape 0 : choisissez votre environnement de secours

Utilisez celui qui vous donne un shell avec des outils de disque de base :

• GRUB « Advanced options » → recovery mode (souvent suffisant).
• Initramfs emergency shell (fonctionne, mais outils limités).
• Installateur Debian en mode rescue, ou un live ISO (meilleur outillage).

Si vous atteignez déjà le shell d’urgence du système, vous n’avez peut-être pas besoin d’un média externe. Mais si des outils comme lsblk ou nano manquent, arrêtez de lutter et bootez un ISO de secours.

Étape 1 : identifiez le système racine et montez-le quelque part prévisible

En mode rescue, / peut être le système de secours, pas votre disque. Trouvez votre partition racine réelle, puis montez-la sous /mnt.

Étape 2 : si vous avez /boot, /boot/efi, /var séparés, montez-les aussi

Monter uniquement la racine suffit souvent pour éditer fstab. Mais si vous prévoyez de reconstruire initramfs ou de toucher la configuration du chargeur, montez /boot et EFI aussi.

Étape 3 : éditez fstab comme si vous désamorciez une bombe

Concrètement :

• Corrigez UUID/LABEL/PARTUUID erronés.
• Corrigez les types de système de fichiers (ext4 vs xfs vs btrfs).
• Pour les montages non critiques (disques de sauvegarde, scratch, NFS), ajoutez nofail et un timeout raisonnable.
• Ne « corrigez » pas en remplaçant par /dev/sdX à moins d’aimer la roulette.

Étape 4 : validez le changement avant de redémarrer

Testez tous les montages depuis la racine installée avec mount -a dans un chroot ou en utilisant mount --fake si approprié. Si ça renvoie des erreurs, vous n’avez pas fini.

Étape 5 : redémarrez une fois, surveillez et vérifiez

Après le redémarrage, confirmez les montages avec findmnt et vérifiez que le démarrage a atteint la target voulue.

Deuxième petite blague, parce qu’on y est tous passés : Chaque fois que vous redémarrez pour « voir si ça a marché », un ingénieur stockage perd un peu de foi en l’humanité.

Tâches pratiques : commandes, sorties et décisions

Voici les tâches de niveau on-call que j’exécute réellement. Chaque tâche inclut : la commande, un exemple de sortie, ce que ça signifie, et la décision que vous prenez. Exécutez-les dans l’ordre, ou sautez à celle qui répond à votre question du moment.

Task 1: See what systemd thinks failed (from emergency/rescue shell)

cr0x@server:~$ systemctl --failed
  UNIT                       LOAD   ACTIVE SUB    DESCRIPTION
● mnt-data.mount             loaded failed failed  /mnt/data
● local-fs.target            loaded failed failed  Local File Systems

LOAD   = Reflects whether the unit definition was loaded properly.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed.

Ce que ça signifie : une unité de montage a échoué et a entraîné local-fs.target. C’est pourquoi le démarrage s’est arrêté.

Décision : examinez mnt-data.mount et la ligne correspondante dans fstab. Déterminez si elle doit être requise ou optionnelle (nofail).

Task 2: Pull the exact error from the journal

cr0x@server:~$ journalctl -xb --no-pager | tail -n 30
Dec 29 09:18:12 server systemd[1]: Mounting /mnt/data...
Dec 29 09:18:12 server mount[512]: mount: /mnt/data: special device UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999 does not exist.
Dec 29 09:18:12 server systemd[1]: mnt-data.mount: Mount process exited, code=exited, status=32/n/a
Dec 29 09:18:12 server systemd[1]: mnt-data.mount: Failed with result 'exit-code'.
Dec 29 09:18:12 server systemd[1]: Failed to mount /mnt/data.
Dec 29 09:18:12 server systemd[1]: Dependency failed for Local File Systems.
Dec 29 09:18:12 server systemd[1]: local-fs.target: Job local-fs.target/start failed with result 'dependency'.

Ce que ça signifie : l’UUID référencé dans fstab n’est pas présent. Ce n’est pas un problème de corruption du système de fichiers ; c’est un problème d’identité.

Décision : trouvez le bon UUID (ou décidez de rendre le montage optionnel) et corrigez fstab.

Task 3: List all block devices with filesystem metadata

cr0x@server:~$ lsblk -f
NAME        FSTYPE FSVER LABEL  UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme0n1
├─nvme0n1p1 vfat   FAT32 EFI    7A1B-2C3D                             498M     1% /boot/efi
├─nvme0n1p2 ext4   1.0   boot   0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d  712M    18% /boot
└─nvme0n1p3 ext4   1.0   root   4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f   38G    42% /
sda
└─sda1      ext4   1.0   data   9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a

Ce que ça signifie : vous voyez le véritable UUID du disque de données (9c2b8d...). Celui du journal (2b1c2c...) est incorrect.

Décision : mettez à jour /etc/fstab pour utiliser le bon UUID ou le label.

Task 4: Double-check with blkid (more direct, sometimes clearer)

cr0x@server:~$ blkid
/dev/nvme0n1p1: LABEL_FATBOOT="EFI" LABEL="EFI" UUID="7A1B-2C3D" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8f9d0b0a-01"
/dev/nvme0n1p2: LABEL="boot" UUID="0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8f9d0b0a-02"
/dev/nvme0n1p3: LABEL="root" UUID="4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8f9d0b0a-03"
/dev/sda1: LABEL="data" UUID="9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="c2b9c3a1-01"

Ce que ça signifie : mappage autoritatif du périphérique vers l’UUID/ LABEL du système de fichiers.

Décision : privilégiez UUID= ou LABEL= dans fstab. Évitez /dev/sda1 sauf si vous êtes dans un environnement contrôlé et comprenez le risque.

Task 5: Mount the installed system’s root from a rescue ISO

cr0x@server:~$ mount /dev/nvme0n1p3 /mnt
cr0x@server:~$ ls /mnt
bin  boot  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

Ce que ça signifie : vous avez monté le vrai système racine sur /mnt.

Décision : éditez /mnt/etc/fstab, pas /etc/fstab du système de secours.

Task 6: Inspect the broken fstab line

cr0x@server:~$ sed -n '1,200p' /mnt/etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f /     ext4  defaults,errors=remount-ro 0 1
UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4  defaults                  0 2
UUID=7A1B-2C3D                            /boot/efi vfat umask=0077              0 1
UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999 /mnt/data ext4 defaults                0 2

Ce que ça signifie : le montage de données référence un UUID qui n’est pas présent sur la machine.

Décision : remplacez cet UUID par le bon, ou commentez la ligne et ajoutez une version plus sûre.

Task 7: Fix fstab quickly and safely (use a real editor, but here’s a minimal patch)

cr0x@server:~$ cp -a /mnt/etc/fstab /mnt/etc/fstab.bak.$(date +%s)
cr0x@server:~$ sed -i 's/UUID=2b1c2c1a-9c43-4b4b-9d63-0a6b7c3d9999/UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a/' /mnt/etc/fstab
cr0x@server:~$ tail -n 5 /mnt/etc/fstab
UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f /     ext4  defaults,errors=remount-ro 0 1
UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4  defaults                  0 2
UUID=7A1B-2C3D                            /boot/efi vfat umask=0077              0 1
UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults                0 2

Ce que ça signifie : vous avez patché le mauvais UUID vers le bon, et vous avez fait une sauvegarde au préalable (bien).

Décision : validez en tentant les montages avant de redémarrer.

Task 8: Create mountpoint if the typo was “directory doesn’t exist”

cr0x@server:~$ mkdir -p /mnt/mnt/data
cr0x@server:~$ ls -ld /mnt/mnt/data
drwxr-xr-x 2 root root 4096 Dec 29 09:27 /mnt/mnt/data

Ce que ça signifie : le point de montage existe maintenant dans la racine du système installé.

Décision : si le seul échec était « point de montage inexistant », cela peut suffire à réparer le démarrage. Validez néanmoins avec un test de montage.

Task 9: Test mounts against the installed system’s fstab (without chroot)

cr0x@server:~$ mount -a -T /mnt/etc/fstab -R /mnt
cr0x@server:~$ findmnt -R /mnt | tail -n 8
/mnt                 /dev/nvme0n1p3 ext4   rw,relatime,errors=remount-ro
/mnt/boot            /dev/nvme0n1p2 ext4   rw,relatime
/mnt/boot/efi        /dev/nvme0n1p1 vfat   rw,relatime,fmask=0077,dmask=0077
/mnt/mnt/data        /dev/sda1      ext4   rw,relatime

Ce que ça signifie : tous les systèmes de fichiers listés se sont montés avec succès sous /mnt en utilisant le fstab installé.

Décision : vous pouvez redémarrer avec une forte confiance. Si cette étape échoue, ne redémarrez pas — corrigez l’erreur maintenant.

Task 10: If you need chroot (for initramfs rebuilds or systemctl checks)

cr0x@server:~$ mount --bind /dev  /mnt/dev
cr0x@server:~$ mount --bind /proc /mnt/proc
cr0x@server:~$ mount --bind /sys  /mnt/sys
cr0x@server:~$ chroot /mnt /bin/bash
cr0x@server:/# systemctl --failed
0 loaded units listed.

Ce que ça signifie : vous opérez à l’intérieur du système installé. Les échecs d’unités vus plus tôt devraient avoir disparu si le problème de montage était le seul blocage.

Décision : si vous avez modifié quelque chose affectant le démarrage précoce (crypto, LVM, pilotes), régénérez initramfs. Sinon, restez simple.

Task 11: Rebuild initramfs (only when it’s actually relevant)

cr0x@server:/# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.0-amd64

Ce que ça signifie : initramfs a été régénéré. Ceci est pertinent si la découverte de la racine, les hooks crypto, ou les pilotes ont changé — pas pour une simple faute de fstab, mais parfois vous corrigez plusieurs choses à la fois.

Décision : si vous avez modifié la configuration de la pile disque, faites-le. Si vous n’avez corrigé qu’un montage optionnel, vous pouvez sauter cette étape pour réduire le risque.

Task 12: Verify fstab syntax and spot tabs/spaces issues before reboot

cr0x@server:/# awk 'NF && $1 !~ /^#/ {print NR ": " $0}' /etc/fstab
2: UUID=4a3b2b89-1f3a-4e8a-9a2d-1c0a0b9e2c5f / ext4 defaults,errors=remount-ro 0 1
3: UUID=0b6e9b2a-5f5d-4f57-8e3d-1f1db4dd2e0d /boot ext4 defaults 0 2
4: UUID=7A1B-2C3D /boot/efi vfat umask=0077 0 1
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults 0 2

Ce que ça signifie : chaque ligne active a des champs ; pas de troncature évidente. Cela ne détecte pas toutes les erreurs sémantiques, mais cela attrape « j’ai accidentellement supprimé la moitié d’une ligne ».

Décision : si une ligne semble malformée, corrigez-la maintenant. Un fstab syntaxiquement cassé est l’une des rares façons de transformer un problème trivial en un grand spectacle.

Task 13: If the mount is non-critical, make boot resilient

cr0x@server:/# cp -a /etc/fstab /etc/fstab.bak.$(date +%s)
cr0x@server:/# grep -n '/mnt/data' /etc/fstab
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults 0 2
cr0x@server:/# sed -i 's|/mnt/data ext4 defaults|/mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s|' /etc/fstab
cr0x@server:/# grep -n '/mnt/data' /etc/fstab
5: UUID=9c2b8d11-8c74-4e2a-a5a5-b0d2f80e0a4a /mnt/data ext4 defaults,nofail,x-systemd.device-timeout=10s 0 2

Ce que ça signifie : si le disque disparaît plus tard, le démarrage ne bloquera plus indéfiniment. C’est opérationnellement sensé pour des montages non nécessaires au fonctionnement du système.

Décision : faites cela pour les volumes de sauvegarde, l’espace temporaire, ou les NFS « agréables à avoir ». Ne le faites pas pour /, /var, ou tout ce dont vos services ont besoin — les ignorer silencieusement provoquerait des pannes étranges.

Task 14: Exit, unmount cleanly, and reboot

cr0x@server:/# exit
cr0x@server:~$ umount -R /mnt
cr0x@server:~$ reboot

Ce que ça signifie : vous quittez en laissant le système dans un état cohérent. Le démontage réduit le risque d’un journal sale provenant de l’environnement de secours.

Décision : si umount -R se plaint de montages occupés, vérifiez s’il y a des shells encore dans /mnt et faites-les quitter. Ne coupez pas l’alimentation sauvagement à moins d’aimer ajouter une réparation de système de fichiers à votre journée.

Erreurs courantes : symptôme → cause racine → correction

Cette section est volontairement directe. La plupart des échecs de démarrage liés à fstab sont des récidivistes.

1) Le démarrage tombe en mode emergency : « special device UUID=… does not exist »

Symptôme : le journal montre un UUID manquant ; l’unité de montage échoue ; local-fs.target échoue.

Cause racine : UUID incorrect dans fstab (faute de frappe, disque remplacé, cloné, ou système de fichiers reformaté).

Correction : trouvez le bon UUID avec lsblk -f/blkid, mettez à jour /etc/fstab, validez avec mount -a -T ... -R .... Si le montage est optionnel, ajoutez nofail et un court x-systemd.device-timeout.

2) Gel pendant 90 secondes (ou plus) : « Timed out waiting for device »

Symptôme : démarrage lent, puis emergency ; systemd indique un timeout du périphérique.

Cause racine : systemd a attendu un périphérique de bloc absent ou apparaissant tard (USB/SAN/iSCSI), et le timeout est par défaut/trop long.

Correction : décidez si le montage est requis. Sinon, utilisez nofail,x-systemd.device-timeout=10s. S’il est requis, corrigez la découverte du périphérique sous-jacent (multipath, iSCSI ordering, pilotes, hooks initramfs manquants).

3) « Le point de montage n’existe pas »

Symptôme : montage échoue instantanément ; le journal indique un répertoire manquant.

Cause racine : faute de frappe dans le point de montage ou répertoire supprimé (souvent lors d’un nettoyage ou d’un rm -rf malencontreux).

Correction : créez le répertoire sur la racine : mkdir -p /mnt/<mountpoint> (ou dans un chroot). Confirmez les permissions si le répertoire est utilisé par des services.

4) « wrong fs type, bad option, bad superblock »

Symptôme : mount signale des problèmes de superbloc ; peut tomber en emergency.

Cause racine : type de système de fichiers incorrect dans fstab, ou corruption réelle, ou tentative de montage de la mauvaise partition au mauvais emplacement.

Correction : confirmez le type réel avec blkid. Si ext4 : lancez fsck -f depuis un rescue (non monté). Si xfs : utilisez xfs_repair (et comprenez le risque). Si btrfs : utilisez btrfs check avec prudence. Si vous avez ciblé la mauvaise partition, corrigez la ligne fstab pour viser le bon UUID.

5) Ligne NFS/CIFS bloque le démarrage

Symptôme : démarrage s’arrête ou se retarde fortement ; les logs mentionnent des échecs de montage distant.

Cause racine : réseau pas prêt quand systemd tente le montage ; _netdev manquant ou approche d’automount manquante.

Correction : ajoutez _netdev,nofail,x-systemd.automount pour les partages non critiques ; ou assurez des dépendances systemd correctes. S’il est critique, préférez un ordonnancement explicite et des timeouts, pas de l’espoir.

6) « Vous avez corrigé fstab, mais ça ne démarre toujours pas »

Symptôme : même échec après redémarrage ; vous êtes certain d’avoir édité.

Cause racine : vous avez édité le /etc/fstab du système de secours, pas celui installé ; ou vous avez monté la mauvaise partition racine ; ou vous avez plusieurs racines (LVM, snapshots).

Correction : vérifiez que vous avez monté la racine installée sur /mnt et édité /mnt/etc/fstab. Confirmez avec cat /mnt/etc/debian_version et ls /mnt contenant les répertoires attendus et les fichiers spécifiques à l’hôte.

Trois mini-histoires d’entreprise tirées de la vie réelle (anonymisées)

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

Ils ont migré un service interne moyen vers du nouveau matériel : même Debian, même stack applicatif, « juste des disques plus rapides ». Le plan était de rsync le système racine, attacher un second disque pour les données, et reproduire la disposition de montage. Simple. Quelqu’un a donc copié /etc/fstab de l’ancienne machine comme point de départ.

L’hypothèse erronée était subtile : « les UUID seront différents, mais on les corrigera plus tard. » L’équipe a corrigé les évidents : root et boot. Ils ont manqué une seule ligne pour /var/lib/app qui faisait référence à un UUID du disque de données du serveur précédent. Ce répertoire existait aussi sur la racine, donc personne n’a remarqué pendant les vérifications préalables. Il se montait « bien » — selon l’identité de l’ancien serveur, qui bien sûr n’existait pas sur la nouvelle machine.

Au premier démarrage, systemd a tenté de le monter, a échoué et est tombé en mode emergency. La fenêtre de migration brûlait. On a commencé à débattre si le contrôleur RAID était défaillant. Quelqu’un a suggéré de réinstaller l’image. Le classique : traiter un problème de configuration comme une panne matérielle parce que le matériel semble plus « réel ».

La correction a pris quatre minutes quand quelqu’un a calmé le bruit. En mode rescue, ils ont exécuté systemctl --failed, vu l’unité de montage exacte, lancé lsblk -f pour identifier le vrai UUID de la partition de données, et patché fstab. Ils ont ensuite ajouté x-systemd.device-timeout=10s pour éviter que de futurs boots de staging ne se bloquent quand l’équipe stockage « retire temporairement » un LUN.

La leçon est ennuyeuse : ne copiez pas fstab entre machines sans une étape explicite de réconciliation. Les UUID ne sont pas de la décoration. Ils sont la vérité sur laquelle votre démarrage repose.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre entreprise avait une flotte de serveurs Debian qui écrivaient beaucoup de logs et métriques. Quelqu’un a décidé d’optimiser l’I/O disque en montant un grand volume « scratch » avec des options agressives et en séparant /var sur sa propre partition. L’idée était bonne : isoler le churn, empêcher la racine de se remplir, et réduire la taille des sauvegardes.

Le retour de bâton est venu d’un déploiement à moitié terminé. Ils ont ajouté un nouveau montage /var dans fstab en utilisant des chemins /dev/disk/by-id/… qui étaient stables sur la machine de test. Sur le matériel de production, les IDs de disque différaient parce que les achats ont pris un modèle différent en milieu de trimestre. Le périphérique de montage n’existait tout simplement pas sur un sous-ensemble de nœuds.

Ces nœuds ne sont pas tombés de manière élégante. Certains ont démarré lentement parce que systemd attendait. D’autres sont tombés en emergency parce que /var était requis et n’était pas marqué nofail (ni ne devrait l’être). Pendant ce temps, l’équipe tentait aussi de réduire le temps de démarrage en raccourcissant les timeouts pour des services non liés. Le débogage est devenu un carnaval de correctifs partiels.

Ils ont récupéré rapidement avec une approche cohérente : ISO de secours, monter la racine, vérifier les périphériques réels avec lsblk -f, remplacer la référence by-id par des UUID de système de fichiers, puis tester mount -a sous la racine installée avant de redémarrer. Plus tard ils ont amélioré le déploiement en étiquetant les systèmes de fichiers d’une manière cohérente et en utilisant LABEL= pour les partitions que les humains manipulent fréquemment.

La leçon : une « optimisation » qui augmente la variabilité entre matériels n’est pas une optimisation. C’est de la dette avec un joli nom.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Un environnement de services financiers avait une politique qui paraissait strictement pénible : tout changement à /etc/fstab nécessitait une pré-vérification et une post-vérification. La pré-vérification était : vérifier que la cible existe (blkid), vérifier que le répertoire de montage existe, et exécuter un test de montage à sec dans un shell de maintenance. La post-vérification était : confirmer avec findmnt et s’assurer que les targets de démarrage sont propres.

Une nuit, un changement de stockage a retiré un volume secondaire d’un lot de serveurs à cause d’une erreur de zonage en amont. Ce n’était pas malveillant ; juste une personne avec un tableur et une longue journée. Les serveurs ont redémarré dans le cadre d’une maintenance de routine.

Sans précautions, ces boîtes seraient restées en emergency. Mais ces montages secondaires étaient intentionnellement marqués nofail avec un court x-systemd.device-timeout, car ils servaient des exports pour un job d’analyse non critique. Les systèmes ont démarré, les services de base sont montés, et la surveillance a signalé le système de fichiers manquant comme une alerte applicative plutôt qu’une panne totale.

Ce qui les a sauvés n’était pas du génie. C’était de la classification : les montages critiques sont stricts ; les montages non critiques sont résilients. Et le processus de changement avait suffisamment de friction pour forcer l’ingénieur à se poser la question : « Si ce disque manque, le démarrage doit-il s’arrêter ? »

La leçon : la meilleure technique de fiabilité est souvent un « c’est optionnel » bien placé combiné à une validation que c’est vraiment optionnel.

Listes de contrôle / plans pas à pas à exécuter sous stress

Checklist A: Quickest path if you already have an emergency shell on the host

1. Exécuter systemctl --failed pour identifier le nom de l’unité de montage.
2. Exécuter journalctl -xb et lire la ligne d’échec du montage. Ne pas survoler.
3. Exécuter lsblk -f et confirmer que le bon UUID/LABEL existe.
4. Éditer /etc/fstab (faire d’abord une copie de sauvegarde).
5. Si le montage est non critique : ajouter nofail,x-systemd.device-timeout=10s.
6. Exécuter mount -a. Si ça renvoie une erreur, vous n’avez pas fini.
7. Exécuter systemctl daemon-reload (pas toujours nécessaire, mais ça clarifie lors d’itérations).
8. Redémarrer une fois.

Checklist B: Safest path using a rescue ISO (recommended)

1. Bootez un ISO de secours/environnement live.
2. lsblk -f pour identifier la partition racine installée.
3. mount /dev/<root> /mnt.
4. Si des partitions séparées existent : montez-les sous /mnt (par ex. /boot, /boot/efi).
5. Sauvegardez /mnt/etc/fstab.
6. Éditez /mnt/etc/fstab avec des UUID corrects et des options sensées.
7. Validez avec mount -a -T /mnt/etc/fstab -R /mnt.
8. Si nécessaire : bind-montez /dev, /proc, /sys, puis chroot /mnt.
9. Quittez le chroot, umount -R /mnt, redémarrez.

Checklist C: When you must boot now, and fix later (triage mode)

1. Dans l’environnement de secours, commentez la/les ligne(s) en échec dans fstab ou marquez-les nofail.
2. Assurez-vous que les montages essentiels restent stricts (/, /var, /boot si utilisé).
3. Validez avec mount -a.
4. Démarrez en multi-user et corrigez proprement avec gestion du changement : corrigez les UUID, vérifiez les dépendances applicatives, et planifiez un remontage/restart contrôlé.

Checklist D: Post-recovery verification (don’t skip)

1. findmnt et confirmez que chaque montage requis est présent et correct.
2. systemctl --failed est vide (ou ne montre que des échecs non critiques attendus).
3. journalctl -b -p warning ne montre pas de réessais ou de timeouts de montage.
4. Confirmez l’identité des disques : lsblk -f correspond à fstab.
5. Si vous avez changé le comportement des montages optionnels, vérifiez que l’application gère correctement l’absence (et génère une alerte).

FAQ

1) Dois‑je utiliser UUID, LABEL, PARTUUID ou /dev/sdX dans fstab ?

Utilisez UUID pour la plupart des systèmes de fichiers. Utilisez LABEL si vous avez une convention stricte de labels et souhaitez une lisibilité humaine. Évitez /dev/sdX pour tout ce qui compte ; l’énumération des périphériques change souvent après des changements matériels ou firmware. PARTUUID est utile quand vous cherchez à cibler l’identité d’une partition avant même qu’un système de fichiers n’existe, mais pour des montages normaux UUID est le choix usuel.

2) Mon système tombe dans initramfs. Est‑ce encore un problème de fstab ?

Parfois. Si la racine ne peut pas être montée, vous atterrissez dans initramfs avant que systemd ne tourne. Ce n’est généralement pas fstab (la racine est contrôlée par la ligne de commande du noyau et l’initramfs), mais vous pouvez avoir des problèmes fstab plus tard qui vous envoient en emergency. Déterminez d’abord où vous êtes : invite initramfs vs shell d’urgence systemd.

3) Est‑il sûr de commenter la ligne fstab en échec pour booter ?

Sûr pour les montages non critiques. Dangereux pour les montages que les applications attendent pour fonctionner correctement (bases de données, /var, files persistantes). Si vous commentez un montage requis, l’hôte démarrera dans un état « ça marche jusqu’à ce que ça casse » où les services écriront des données au mauvais endroit.

4) Quelle est la différence entre rescue mode et emergency mode ?

Emergency mode est le shell root minimal avec très peu de services ; rescue mode lance plus du système (comme des montages de base et parfois le réseau, selon la configuration). Les deux servent à la récupération, mais emergency mode est ce que vous obtenez quand systemd juge le démarrage normal dangereux.

5) Pourquoi systemd a bloqué le démarrage pour un montage qui n’est pas si important ?

Parce que vous le lui avez dit. L’hypothèse par défaut pour les entrées dans fstab est qu’elles sont des systèmes de fichiers locaux requis. Si le montage est optionnel, ajoutez nofail et pensez à x-systemd.device-timeout=. S’il s’agit d’un montage réseau, ajoutez _netdev et envisagez x-systemd.automount pour éviter le blocage au démarrage.

6) Comment valider fstab sans redémarrer ?

Sur un système en fonctionnement : mount -a tentera de monter tout ce qui n’est pas monté. Depuis un ISO de secours : montez la racine installée sous /mnt et utilisez mount -a -T /mnt/etc/fstab -R /mnt pour tester contre le fstab installé sans chroot.

7) J’ai changé les UUID en reformatant un système de fichiers. Et maintenant ?

Mettez à jour fstab pour référencer le nouvel UUID et validez avec lsblk -f/blkid. Si c’était un système de fichiers de données utilisé par des applications, confirmez la propriété/permissions et que le point de montage est correct — sinon le service peut créer un nouvel arbre de répertoires vide sur la racine et commencer à écrire là par erreur.

8) Mon montage fonctionne manuellement mais échoue au démarrage. Pourquoi ?

Le contexte au démarrage est différent. Raisons courantes : point de montage absent tôt, réseau pas encore monté pour NFS/CIFS, dépendances non exprimées (_netdev), volumes chiffrés/LVM non activés assez tôt, ou timeouts systemd. Consultez journalctl -b pour l’erreur au démarrage et comparez avec votre commande de montage manuelle.

9) Dois‑je lancer fsck automatiquement quand le démarrage échoue ?

Seulement si le log indique une corruption de système de fichiers ou un journal non propre. Si le log dit « device does not exist », fsck est inutile. S’il dit « bad superblock » ou « needs journal recovery », alors oui — lancez l’outil adéquat pour le système de fichiers, et uniquement sur un système de fichiers non monté.

10) Puis‑je prévenir entièrement cette classe d’incident ?

Vous pouvez beaucoup la réduire : utilisez des identifiants stables (UUID/LABEL), classez les montages requis vs optionnels, définissez des timeouts sensés, et validez les changements de fstab avec mount -a avant de redémarrer. Aussi, ne déployez pas d’éditions de fstab sans plan de rollback et accès console.

Conclusion : étapes suivantes pour éviter une récidive

Corriger une panne de démarrage causée par fstab est rarement difficile. C’est juste impitoyable. Le chemin le plus rapide est toujours le même : lisez l’erreur, vérifiez l’identité, éditez le bon fichier, testez les montages, redémarrez une fois.

Faites ceci ensuite :

• Classifiez les montages dans votre parc : requis vs optionnels. Utilisez nofail uniquement là où l’absence est vraiment acceptable.
• Standardisez les identifiants : UUID pour la plupart, labels quand la lisibilité humaine est nécessaire et que vous contrôlez le nommage.
• Ajoutez de la résilience au montage pour les périphériques optionnels : timeouts courts, éviter le blocage au démarrage, et alerter au niveau applicatif.
• Discipline de changement : chaque édition de fstab reçoit un cp -a de sauvegarde, puis une validation mount -a avant redémarrage.
• Gardez une voie de secours : accès IPMI/console, un ISO de secours connu bon, et un runbook qui ne suppose pas que le réseau vous sauvera.

Si vous traitez /etc/fstab comme du code — relu, validé et déployé avec intention — il cesse d’être une loterie de démarrage et redevient ce qu’il a toujours voulu être : une table de montages ennuyeuse.