fsck ne fsck pas (impossible de définir des drapeaux de superbloc)

Après un arrêt impur sur un appareil basé sur une carte SD, j'ai sorti la carte SD vers fsckle système de fichiers racine. Cela a conduit à des variations sur les points suivants:

e2fsck 1.43.1 (08-Jun-2016)
/dev/sdc2: recovering journal
Superblock needs_recovery flag is clear, but journal has data.
Run journal anyway<y>? no
Clear journal<y>? no
e2fsck: unable to set superblock flags on /dev/sdc2

Ici, j'ai répondu "non" les deux fois mais il n'y a pas de séquence de oui / non qui ne mène pas immédiatement au même résultat.

Le système de fichiers peut être monté et sur inspection occasionnelle semble correct; cela fonctionne également très bien dans l'appareil, et c'est le système de fichiers racine (en fait, il s'est avéré ne pas être très bien, voir les commentaires; tldr certains répertoires irrémédiablement corrompus).

J'avais ddla partition (8 Go) dans un fichier et j'ai essayé fsck dessus. De façon intéressante:

e2fsck 1.43.1 (08-Jun-2016)
plush.rootfs: recovering journal
Clearing orphaned inode 18290 (uid=0, gid=0, mode=0100644, size=34096)
Clearing orphaned inode 18270 (uid=0, gid=0, mode=0100644, size=38916)
Clearing orphaned inode 18250 (uid=0, gid=0, mode=0100644, size=1128076)
Clearing orphaned inode 11411 (uid=0, gid=0, mode=0100644, size=293108)
Setting free inodes count to 406127 (was 408580)
Setting free blocks count to 1305622 (was 1347486)
plush.rootfs: clean, 60209/466336 files, 604906/1910528 blocks (check after next mount)

A la suite fsckpassé propre, l'image peut être monté, et fsck -faprès cela passe aussi.

Mais le système de fichiers sur la carte à partir de laquelle l'image de copie de bloc brute a été créée a toujours le même problème - sauf que celui systemd-fsckqui a lieu pendant le démarrage enregistre le système de fichiers comme "propre". Par la suite cependant, un arrêt correct, retirer la carte et fsckréessayer à partir d'une autre boîte présente la même erreur.

Chaque fois que l'original est monté sur une autre machine, syslog note:

kernel: EXT4-fs (sdc2): 4 orphan inodes deleted
kernel: EXT4-fs (sdc2): recovery complete

Puisque j'ai tout sauvegardé, je suis prêt à essayer quoi que ce soit ici. Je pourrais simplement oublier cela et restaurer la partition à partir de l'image apparemment fixe, mais cela ne semble pas être une solution très satisfaisante, car cela signifie que fsck a échoué cryptiquement à résoudre un problème mineur.

Je soupçonne que cela va se transformer en une question "demande de documentation officielle" concernant des choses comme les besoins recovery_flag (ou tout simplement la question "Qu'est-ce que cela signifie?"), Donc toutes les suggestions dans ce sens sont appréciées.

Je viens de rencontrer ce même problème. Après avoir débogué le problème avec le e2fsckresponsable, nous avons réalisé que la carte SD était cassée. Il acceptait les écritures sans erreur, mais il n'écrivait pas réellement les données sur la carte. La carte SD était effectivement en lecture seule.

Il semble que la carte soit entrée dans une sorte de mode de sécurité intégrée, où les données pouvaient toujours être lues, mais rien écrit.

Le e2fsckmessage unable to set superblock flagssignifie qu'il a essayé d'écrire dans le superbloc pour marquer le journal comme traité, ce qui s'est produit sans erreur, mais lorsqu'il est allé relire le superbloc, il a toujours indiqué que le journal devait être relu. En d'autres termes, les modifications écrites dans le superbloc n'ont pas été enregistrées sur le support de stockage.

La carte que j'utilise qui a ce problème est un microSD Samsung Evo 16 Go, que je mentionne juste au cas où c'est un problème commun avec ces cartes.

J'ai pu tester cela en utilisant ddpour écrire 4096 octets depuis /dev/zerosur la carte au bloc 0, puis j'ai relu à partir de la carte et au lieu d'obtenir tous les zéros comme je le devrais, j'ai toujours le superbloc ext4 inchangé d'origine.

Je suis en train de déplacer les données sur une nouvelle carte et de voir si je peux obtenir un remplacement de Samsung, qui semble offrir une garantie de 10 ans sur les cartes SD.

MISE À JOUR: Samsung a remplacé la carte de 16 Go par une carte de 32 Go dans la même série Evo, alors devinez que je ne peux pas trop me plaindre!

Je sais que c'est un vieux fil de discussion, mais je me suis dit que j'offrirais un aperçu.

Cela semble être la façon dont les cartes SD meurent d'une mort naturelle. Le nombre de cycles de lecture / écriture que les cartes SD peuvent subir est nettement inférieur à la plupart des autres supports considérés comme «lecture / écriture». Lorsque cela aura été épuisé, la carte passera en mode lecture seule, mais ne vous en informera pas. Beaucoup de choses penseront qu'elles écrivent sur la carte grâce à la mise en cache du système d'exploitation, etc., mais rien ne colle jamais.

Une excellente façon de tuer une carte SD est de la monter en tant que partition de swap ou quelque chose de très intensif en lecture / écriture. Vous seriez surpris de la rapidité avec laquelle vous pouvez tuer une carte de cette façon. J'ai constaté que l'exécution de knoppix sur une carte sd ou une clé USB ne durera qu'un mois ou deux, selon la qualité de la carte et l'intensité de l'utilisation de knoppix. (Depuis, je suis passé à l'exécution de knoppix sur un lecteur SSD USB qui a duré quelques années maintenant).