fsck wird nicht fsck (Superblock-Flags können nicht gesetzt werden)

Nach einem unsauberen Herunterfahren auf einem SD-Karten-basierten Gerät habe ich die SD-Karte in fsckdas Root-Dateisystem herausgenommen. Dies führte zu Abweichungen bei folgenden Punkten:

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

Hier habe ich beide Male mit "Nein" geantwortet, aber es gibt keine Folge von Ja / Nein, die nicht sofort zum gleichen Ergebnis führt.

Das Dateisystem kann gemountet werden und bei gelegentlicher Überprüfung erscheint es in Ordnung. es funktioniert auch gut im Gerät, und das ist das Root-Dateisystem (tatsächlich stellte sich heraus, dass es nicht ganz in Ordnung ist, siehe Kommentare; einige unwiederbringlich beschädigte Verzeichnisse).

Ich würde dddie Partition (8 GB) in eine Datei umwandeln und fsck darauf versuchen. Interessant:

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)

Nach einer anschließenden fsckBereinigung kann das Image gemountet werden, und fsck -fdanach ist es ebenfalls erfolgreich.

Das Dateisystem auf der Karte, von der das Rohblockkopie-Image erstellt wurde, weist jedoch immer noch das gleiche Problem auf - mit der Ausnahme, dass systemd-fsckdas Dateisystem , das während des Startvorgangs stattfindet, das Dateisystem als "sauber" protokolliert. Anschließend führt jedoch ein ordnungsgemäßes Herunterfahren, Herausnehmen der Karte und fsckerneutes Ausprobieren aus einer anderen Box zu demselben Fehler.

Wenn das Original auf einem anderen Computer bereitgestellt wird, werden im Syslog folgende Hinweise angezeigt:

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

Da ich alles gesichert habe, bin ich offen dafür, hier etwas zu versuchen. Ich könnte dies einfach vergessen und die Partition aus dem scheinbar festen Image zurückbrennen, aber das scheint keine sehr zufriedenstellende Lösung zu sein, da dies bedeutet, dass fsck bei der Lösung eines geringfügig aussehenden Problems kryptisch gescheitert ist.

Ich vermute, dass dies zu einer Frage "Anfrage nach offizieller Dokumentation" in Bezug auf Dinge wie " Bedarfswiederherstellungsflag" (oder einfach nur "Was bedeutet das?" - Frage wird. Daher sind Vorschläge in dieser Richtung willkommen.

ext4 fsck sd-card

— Goldlöckchen
quelle

Gibt es irgendetwas im Kernel, das über Gerätefehler protokolliert? Dies wäre nicht das erste Mal, dass eine SD-Karte plötzlich schreibgeschützt wird.

— Mark Plotnick

@ MarkPlotnick Nein, und es ist beschreibbar. Das Letzte im Protokoll vor dem Problem war ein Neustart des Systems (das Gerät ist kopflos und reagiert nach einer langen Zeit nicht mehr apt upgrade). Danach wird ein normaler Start protokolliert - und das systemd-fsck sagt "clean" (ich werde das in bearbeiten), aber der Versuch, fsck außerhalb dieses Kontexts zu versuchen, schlägt immer noch fehl.

— Goldlöckchen

Ihr fsck auf der Kopie löschte 4 Inodes, korrigierte aber die Anzahl der freien Inodes, indem Sie sie um 2453 Inodes reduzierten! Das ist enorm. Überprüfen Sie, ob das Gerät genügend Strom erhält.

— Meuh

@meuh Ich bemerke, wann immer es auf der Big Box montiert ist. Syslog bezieht sich auf diese 4 Inodes (oben bearbeitet). Einige Dinge auf dem fs haben sich als durcheinander erwiesen (aktualisierte Kernelmodule! \ O /), also habe ich eine neue Karte gebrannt und werde an der alten festhalten, falls ich die Gelegenheit habe, mich weiter damit zu beschäftigen. Es ist nicht gerade neu - eine nicht markenrechtlich geschützte Schnäppchen-Klasse-10-Karte, die möglicherweise einige Jahre lang rund um die Uhr im Einsatz ist, also ... Ich glaube nicht, dass es eine Möglichkeit gibt, zu überprüfen, ob eine SD-Karte endgültig nicht mehr funktioniert , aber ich denke es könnte das sein. Die Stromversorgung sollte in Ordnung sein, kann aber unter bestimmten Bedingungen zweifelhaft sein.

— Goldlöckchen

Ist es nicht wirklich scheiße, wenn genau das Tool, das Ihr Problem beheben soll, aufgrund der Art des Problems nicht funktioniert? Fazit: Das Tool ist schlecht und sollte repariert werden.

— März 2377

Antworten:

Ich bin gerade auf dasselbe Problem gestoßen. Nach dem Debuggen des Problems mit dem e2fsckBetreuer stellten wir fest, dass die SD-Karte defekt war. Es wurden fehlerfreie Schreibvorgänge akzeptiert, aber die Daten wurden nicht auf die Karte geschrieben. Die SD-Karte war effektiv schreibgeschützt.

Es scheint, dass die Karte in einen ausfallsicheren Modus übergegangen ist, in dem die Daten noch gelesen, aber nichts geschrieben werden konnten.

Die e2fsckNachricht unable to set superblock flagsMittel versuchten , zu dem Superblock zu schreiben , die Zeitschrift zu markieren , wie verarbeitet, die ohne Fehler passiert ist , aber wenn es ging den Super wieder noch angegeben zu lesen , dass die Zeitschrift wiederholt werden muß. Mit anderen Worten, die in den Superblock geschriebenen Änderungen wurden nicht auf dem Speichermedium gespeichert.

Die Karte, die ich mit diesem Problem verwende, ist eine Samsung Evo 16 GB microSD, die ich nur für den Fall erwähne, dass es sich bei diesen Karten um ein häufiges Problem handelt.

Ich konnte dies testen, indem ich bei Block 0 dd4096 Bytes von /dev/zeroauf die Karte schrieb, dann las ich von der Karte zurück und anstatt alle Nullen zu erhalten, wie ich sollte, bekam ich immer noch den ursprünglichen unveränderten ext4-Superblock.

Ich bin gerade dabei, die Daten auf eine neue Karte zu übertragen und dann zu prüfen, ob ich einen Ersatz von Samsung erhalten kann, das anscheinend eine 10-jährige Garantie auf SD-Karten bietet.

UPDATE: Samsung hat die 16-GB-Karte durch eine 32-GB-Karte aus derselben Evo-Serie ersetzt. Ich kann mich also nicht allzu sehr beschweren!

— Malvineous
quelle

"wo die Daten noch gelesen werden konnten, aber nichts geschrieben wurde" -> Das fs war beschreibbar.

— Goldlöckchen

@goldilocks: Klingt so, als ob dein fs-Superblock möglicherweise nicht beschreibbar war. Außerdem schien mein fs dank Caching beschreibbar zu sein. Erst nach dem Abmelden und erneuten Bereitstellen bemerkte ich, dass Änderungen verloren gingen.

— Malvineous

Es war keine Illusion aufgrund von Caching.

— Goldlöckchen

Ich weiß, dass dies ein alter Thread ist, aber ich dachte, ich würde einen Einblick bieten.

Dies scheint die Art und Weise zu sein, wie SD-Karten eines natürlichen Todes sterben. Die Anzahl der Lese- / Schreibzyklen, die SD-Karten aushalten können, ist wesentlich geringer als bei den meisten anderen Medien, die als "Lesen / Schreiben" betrachtet werden. Wenn dies erschöpft ist, wechselt die Karte in den schreibgeschützten Modus, informiert Sie jedoch nicht darüber. Viele Dinge werden denken, dass sie dank OS-Caching usw. auf die Karte schreiben, aber nichts bleibt jemals hängen.

Eine gute Möglichkeit, eine SD-Karte zu töten, besteht darin, sie als Swap-Partition oder als sehr lesungs- / schreibintensiv einzubinden. Sie wären überrascht, wie schnell Sie eine Karte auf diese Weise töten können. Ich habe festgestellt, dass das Ausführen von Knoppix von einer SD-Karte oder einem USB-Stick nur ein oder zwei Monate dauert, abhängig von der Qualität der Karte und der Intensität der Knoppix-Nutzung. (Ich habe seitdem auf Knoppix von einem USB-SSD-Laufwerk umgestellt, das nun einige Jahre gedauert hat).

— Joe
quelle