J'ai un problème avec ma partition système ext4. Je suis en cours d'exécution 17.04 (mis à niveau à partir de 16.10), mais le problème était déjà présent dans 16.10.
De temps en temps (le plus souvent après avoir réveillé le système de la suspension), le système se bloque avec un ensemble d'erreurs du système de fichiers ext4.
Maintenant, lors de la vérification du système de fichiers avec
Sudo fsck -n /dev/nvme0n1p2
fsck affirme que le système de fichiers est propre
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/nvme0n1p2: clean, 434755/15089664 files, 46490132/60347136 blocks
Cependant, si je force un chèque, je reçois un tas d'erreurs:
Sudo fsck -nf /dev/nvme0n1p2
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning! /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted Orphan linked list found. Fix? no
Inode 131275 was part of the orphaned inode list. IGNORED.
Inode 135221 was part of the orphaned inode list. IGNORED.
Inode 135244 was part of the orphaned inode list. IGNORED.
Inode 135260 was part of the orphaned inode list. IGNORED.
Inode 135263 was part of the orphaned inode list. IGNORED.
Inode 135268 was part of the orphaned inode list. IGNORED.
Deleted inode 135272 has zero dtime. Fix? no
Inode 135274 was part of the orphaned inode list. IGNORED.
Inode 135384 was part of the orphaned inode list. IGNORED.
Inode 135396 was part of the orphaned inode list. IGNORED.
Inode 135697 was part of the orphaned inode list. IGNORED.
Inode 135711 was part of the orphaned inode list. IGNORED.
Inode 135713 was part of the orphaned inode list. IGNORED.
Inode 12059086 was part of the orphaned inode list. IGNORED.
Inode 12061077 was part of the orphaned inode list. IGNORED.
Inode 12062594 was part of the orphaned inode list. IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -(40927357--40927367) -(40927563--40927569) -(40940652--40940653) -(40940676--40940681) -(48296964--48296970) -(48296978--48296984) -(48304145--48304165) -(48304315--48304321) -(48326677--48326690) -(48326733--48326739) -(48326775--48326781)
Fix? no
Free blocks count wrong (13857004, counted=13856542).
Fix? no
Inode bitmap differences: -131275 -135221 -135244 -135260 -135263 -135268 -135272 -135274 -135384 -135396 -135697 -135711 -135713 -12059086 -12061077 -12062594
Fix? no
Free inodes count wrong (14654909, counted=14654758).
Fix? no
/dev/nvme0n1p2: ********** WARNING: Filesystem still has errors **********
/dev/nvme0n1p2: 434755/15089664 files (0.3% non-contiguous), 46490132/60347136 blocks
Maintenant, mon problème est que je ne peux pas réparer ces erreurs, car c'est ma partition système, que je ne peux pas démonter. Mais lorsque je démarre à partir d'un lecteur externe ou en mode de récupération, fsck ne signale aucune erreur, même avec -f. Après le redémarrage de mon système, toutefois, les erreurs persistent. Je ne sais pas comment je pourrais réparer le système de fichiers. Toute aide serait grandement appréciée.
Si vous forcez une vérification du système de fichiers sur un système de fichiers ext4 actuellement monté en mode r/w à l'aide de fsck -nf <filesystem>
, vous obtiendrez toujours des messages d'erreur similaires à ceux que vous avez publiés (, corrompu. Orphan liste liée , inode supprimé ... a zéro dtime ). Le fait que fsck -n <filesystem>
le signale comme étant propre est un peu trompeur ici.
La raison pour laquelle vous ne voyez pas ces erreurs en mode de récupération ou au démarrage à partir d'un lecteur externe est simplement le fait que, dans ce cas, le système de fichiers en question n'est pas monté en mode r/w, ni même du tout.
La page de manuel de e2fsck indique également explicitement:
Notez qu'en général, il n'est pas prudent d'exécuter e2fsck sur des systèmes de fichiers montés. La seule exception est si l'option -n est spécifiée et que les options -c, -l ou -L ne sont pas spécifiées. Cependant, même si cela ne présente aucun danger, les résultats imprimés par e2fsck ne sont pas valides si le système de fichiers est monté. Si e2fsck vous demande si vous devez ou non vérifier un système de fichiers monté, la seule réponse correcte est "non". Seuls les experts qui savent vraiment ce qu’ils font devraient envisager de répondre à cette question de toute autre manière.
Conclusion : Si vous avez l'intention d'utiliser l'indicateur -f
pour fsck, assurez-vous de comprendre à 100% ce qu'il fait. En particulier, son utilisation sur un système de fichiers monté n’est généralement pas ce que vous souhaitez.
La raison pour laquelle vous obtenez des erreurs ext4 lorsque vous sortez de suspendre est un problème totalement différent que vous semblez avoir déjà résolu. Pour des raisons de référence, je vais inclure les liens que vous avez postés dans un commentaire ici, car ils ont été utiles pour résoudre votre problème initial: