Linux / Commande fsck : contrôle de cohérence et précautions de réparation

fsck sélectionne un outil de contrôle propre au système de fichiers pour en vérifier la cohérence et éventuellement le réparer. Identifiez le format et les usages de la cible avant de choisir les options. Une réparation sur un système de fichiers monté peut corrompre les données ; un contrôle sans modification ne remplace pas non plus les conditions d’une analyse fiable.

Identifier le système de fichiers et organiser son arrêt

lsblk -f
findmnt --source /dev/sdb1

/dev/sdb1 est un exemple à remplacer après vérification. lsblk aide à lire les couches et les montages ; blkid aide à identifier le contenu. Le périphérique à contrôler peut être un volume logique ou chiffré, et non la partition physique qui le contient.

Un résultat findmnt vide demande encore de vérifier le contexte, les autres usages et les espaces de noms. Préparez des sauvegardes récupérables, terminez les écritures et démontez normalement le système de fichiers avec la procédure adaptée. Ne démontrez pas ce contrôle sur un volume de production en cours d’utilisation.

La racine du système en fonctionnement ne se détache pas comme un volume de données ordinaire. Une vérification hors ligne peut nécessiter un environnement de récupération ou un système autonome démarré séparément. Si le support présente des erreurs matérielles ou de lecture, la conservation des données et le diagnostic du stockage précèdent les tentatives répétées de réparation logique.

Distinguer affichage de commande et contrôle sans modification

Le frontal générique peut afficher ce qu’il lancerait sans exécuter les contrôleurs :

sudo fsck -N /dev/sdb1

-N majuscule ne vérifie pas le contenu et ne certifie pas son état. Le frontal peut appeler fsck.ext4 ou un autre programme selon le type. Sans cible explicite, fsck peut examiner les systèmes définis dans /etc/fstab : ne l’exécutez donc pas sans argument en pensant demander une aide.

Pour un ext2, ext3 ou ext4 identifié et démonté, la commande suivante demande à e2fsck une ouverture en lecture seule et des réponses négatives aux questions :

sudo e2fsck -n /dev/sdb1

Ne transposez pas -n à tout format comme s’il s’agissait d’un contrat universel du frontal. Le manuel e2fsck distingue également les combinaisons avec -c, -l ou -L ; n’ajoutez pas ces options à l’exemple en supposant conserver toutes ses garanties.

Même lorsque l’utilisation de -n seul évite les modifications sur un système monté, les résultats d’e2fsck sur ce système ne sont pas valides pour conclure à sa cohérence. Le démontage reste donc une condition importante de ce diagnostic. Un système jugé propre peut aussi ne pas subir toutes les passes ; -f demande un contrôle forcé même s’il paraît propre, avec une durée et une portée à prévoir.

La sortie dépend de l’état réel : elle peut signaler un système propre, des incohérences non corrigées ou une erreur opérationnelle. Ne cherchez pas une phrase unique de « succès » et ne passez pas automatiquement à -y lorsqu’un problème apparaît.

Lire les statuts de sortie et les limites des options

fsck et e2fsck peuvent utiliser des codes composés de plusieurs bits. Pour conserver le résultat de l’exemple, sans le perdre derrière une commande d’affichage :

if sudo e2fsck -n /dev/sdb1; then
    check_status=0
else
    check_status=$?
fi
printf 'Statut e2fsck : %s\n' "$check_status"

Ce bloc effectue à nouveau le contrôle : utilisez-le à la place de l’appel précédent si vous avez besoin du statut, et non pour multiplier les analyses. Les codes de référence comprennent :

Plusieurs conditions peuvent se combiner. Un code non nul ne signifie donc pas toujours « le programme n’a pas démarré », et un code 1 n’équivaut pas à 0 : une correction a eu lieu. Consultez aussi les définitions du contrôleur exact ; n’utilisez pas ce tableau pour interpréter tous les outils de tous les formats.

Avec -M, un retour 0 peut signifier que la cible montée a été ignorée, et non qu’elle a été analysée. De même, -V ajoute des détails mais n’empêche pas l’exécution. Lisez donc les options avec leur casse et leur rôle précis.

Choisir la procédure propre au format et vérifier après réparation

Pour XFS, le comportement ordinaire de fsck.xfs consiste à terminer avec succès sans effectuer le contrôle de cohérence complet attendu d’e2fsck. Cela ne prouve pas qu’un volume XFS est sain ; les modes de démarrage forcé et la réparation relèvent d’une procédure différente. Consultez le manuel fsck.xfs et la procédure xfs_repair avant toute intervention.

Pour ext, les modes de réparation interactifs ou automatiques peuvent modifier des métadonnées et le devenir de fichiers endommagés. L’approbation automatique -y accepte les corrections proposées ; elle n’évalue pas pour vous leur impact sur les données. Gardez le diagnostic initial, les sauvegardes et une procédure de récupération adaptée avant de réparer.

Après une réparation autorisée, relisez le résultat et son statut, appliquez les éventuelles exigences de redémarrage puis contrôlez le montage, les journaux et les fichiers importants. Validez aussi le fonctionnement de l’application : une structure de système de fichiers cohérente ne garantit pas à elle seule la cohérence de toutes les données métier.

Le manuel fsck de util-linux définit le frontal et ses statuts. Le manuel e2fsck de e2fsprogs précise les conditions de contrôle de la famille ext et les limites d’un système monté.