Fsck sous Linux : réparer un système de fichiers démonté

Un serveur redémarre en mode d’urgence, une partition refuse de se monter ou le noyau signale des erreurs ext4. La tentation est de lancer immédiatement fsck sur le premier périphérique trouvé. C’est précisément ce qu’il faut éviter : une réparation sur le mauvais volume, ou sur un système de fichiers encore monté, peut aggraver les dégâts.

fsck est un lanceur qui appelle l’outil adapté au système de fichiers. Avant toute correction, vous devez identifier la partition, vérifier son type, confirmer qu’elle n’est plus utilisée et conserver une sauvegarde exploitable. Je commence toujours par un contrôle sans écriture. La réparation vient seulement après.

Identifier la partition et son système de fichiers

Ne vous fiez pas uniquement à un nom comme /dev/sdb1. L’ordre des disques peut changer après un redémarrage ou l’ajout d’un périphérique USB. Affichez le type de système de fichiers, l’UUID, le modèle, le numéro de série et les points de montage :

lsblk -o NAME,SIZE,FSTYPE,UUID,MOUNTPOINTS,MODEL,SERIAL,TYPE
sudo blkid

Le guide sur lsblk sous Linux détaille cette vérification. Si vous travaillez avec LVM, ciblez le volume logique qui contient le système de fichiers, par exemple /dev/mapper/vg_data-lv_archive, pas le volume physique LVM situé en dessous. L’article consacré à LVM et ses différentes couches permet de les distinguer.

Vérifiez ensuite comment la source est utilisée :

findmnt --source /dev/nvme0n1p2
findmnt --target /mnt/data

Une sortie indique que le volume est monté. Une absence de résultat ne suffit pas si vous avez encore un doute : relisez lsblk et findmnt, puis contrôlez l’UUID. Le tutoriel sur les UUID de systèmes de fichiers évite de confondre deux partitions aux noms proches.

Ne jamais réparer un système de fichiers monté

Le noyau peut modifier les métadonnées pendant que fsck essaie de les corriger. Les deux visions du système de fichiers deviennent alors incohérentes. Un montage en lecture seule n’est pas une garantie suffisante pour improviser une réparation : l’outil doit être utilisé dans les conditions prévues par sa documentation.

Pour un volume de données, arrêtez les services qui l’utilisent, quittez les terminaux placés dans son arborescence, puis démontez-le :

sudo fuser -vm /mnt/data
sudo umount /mnt/data
findmnt --source /dev/nvme0n1p2

Si umount répond que la cible est occupée, ne forcez pas. Identifiez le processus avec fuser ou lsof, puis arrêtez proprement le service concerné.

Pour la partition racine, utilisez un média live ou un environnement de secours où cette partition n’est pas montée. Passer simplement en mode mono-utilisateur ou en mode d’urgence ne prouve pas que la racine est démontée. Sur un serveur distant, prévoyez une console KVM, IPMI ou l’accès de secours de l’hébergeur avant le redémarrage.

Commencer par un contrôle sans écriture

La commande suivante montre quel vérificateur fsck lancerait, sans exécuter le contrôle :

sudo fsck -N /dev/nvme0n1p2

Sur un système ext2, ext3 ou ext4 démonté, lancez ensuite un examen forcé en répondant non à toutes les propositions de modification :

sudo e2fsck -f -n /dev/nvme0n1p2
rc=$?
echo "Code e2fsck : $rc"

L’option -n garde le contrôle en lecture seule. L’option -f demande un examen complet même si le système de fichiers paraît propre. Ce contrôle peut être long sur un gros volume. Si le disque remonte des erreurs d’entrée-sortie, des délais d’attente ou des déconnexions, sauvegardez d’abord ce qui reste lisible et vérifiez le matériel. fsck répare une structure logique, pas un disque qui tombe physiquement en panne.

Les messages du noyau peuvent confirmer ce scénario :

sudo dmesg -T | grep -Ei 'I/O error|timeout|reset|EXT4-fs|XFS|BTRFS'
sudo journalctl -k -b -p warning..alert

Le guide sur dmesg et les erreurs du noyau aide à replacer ces alertes dans l’ordre des événements.

Réparer un volume ext4 sans répondre oui partout

Si le contrôle signale des incohérences, vérifiez votre sauvegarde, confirmez encore le périphérique et gardez le volume démonté. Lancez ensuite la réparation interactive :

sudo e2fsck -f /dev/nvme0n1p2

Lisez chaque question avant de valider. Évitez -y par défaut : cette option accepte toutes les corrections, y compris lorsque la situation exige de sauvegarder le volume ou d’examiner le matériel avant d’aller plus loin. Sur une partition importante, une réparation automatique à l’aveugle est un mauvais échange entre vitesse et contrôle.

Quand la commande se termine, capturez immédiatement son code de sortie :

rc=$?
echo "Code e2fsck : $rc"

Lire le code de sortie de fsck

Un code non nul ne signifie pas toujours que la réparation a échoué. Les valeurs principales sont les suivantes :

• 0 : aucune erreur détectée ;
• 1 : erreurs corrigées ;
• 2 : erreurs corrigées, redémarrage nécessaire ;
• 4 : erreurs non corrigées ;
• 8 : erreur de fonctionnement du vérificateur ;
• 16 : erreur d’utilisation ou de syntaxe ;
• 32 : contrôle annulé ;
• 128 : erreur liée à une bibliothèque partagée.

Ces valeurs fonctionnent comme des bits et peuvent s’additionner. Un code 4 impose de ne pas remonter le volume en lecture-écriture comme si tout était réglé. Un code 8 demande de vérifier la commande, le type de système de fichiers, les outils installés et les messages affichés.

XFS et Btrfs utilisent leurs propres outils

fsck n’applique pas la même méthode à tous les systèmes de fichiers. Pour XFS, commencez par un examen sans modification sur le volume démonté :

sudo xfs_repair -n /dev/nvme0n1p2

La réparation s’effectue ensuite avec xfs_repair, toujours hors montage. N’utilisez pas -L comme première tentative : remettre le journal à zéro peut entraîner une perte de métadonnées récentes.

Pour Btrfs, le contrôle prudent est explicitement en lecture seule :

sudo btrfs check --readonly /dev/nvme0n1p2

N’ajoutez pas --repair sans sauvegarde et sans procédure adaptée au problème observé. La documentation Btrfs avertit elle-même de ne pas l’utiliser sans conseil expérimenté. Vérifiez toujours FSTYPE avec lsblk -f avant de choisir l’outil.

Vérifier le volume avant de le remonter

Après une réparation ext4, relancez un contrôle sans écriture. Si le résultat est propre, remontez le volume, puis vérifiez le type, l’espace et les nouveaux messages du noyau :

sudo e2fsck -f -n /dev/nvme0n1p2
sudo mount /mnt/data
findmnt /mnt/data
df -hT /mnt/data
sudo journalctl -k -b -p warning..alert

Pour une partition racine contrôlée au démarrage, consultez aussi les traces du démarrage précédent :

journalctl -b -1 | grep -Ei 'fsck|filesystem|I/O error|EXT4-fs|XFS|BTRFS'
systemctl --failed

La page de manuel fsck décrit le lanceur et ses codes de sortie. Pour ext4, reportez-vous à e2fsck. Les procédures propres à XFS et à Btrfs doivent rester prioritaires sur une commande générique trouvée au hasard.

sudo apt update && sudo apt upgrade