Defekte SD Karte reparieren
Einer meiner Raspberry Pis wollte nicht hochfahren nach einem Reboot. Die SD Karte war leider defekt.
In diesem Beitrag möchte ich euch zeigen, was ich unternommen habe um meine SD Karte noch zu retten (oder auch nicht).
fsck
Das File System Consistency Check Dienstprogramm hat mir bis jetzt immer gute Dienste geleistet, also starte ich damit. Die SD Karte besitzt ein ext4 Dateisystem und ist 16 GB groß.
Code:
# fsck /dev/mmcblk0p2
Und es bricht gleich mal ab...
Code:
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
fsck.ext4: Filesystem revision too high while trying to open /dev/mmcblk0p2
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Der Superblock enthält Informationen über das Dateisystem, wie etwa file system type, size, status, Informationen über andere metadata structures, block counts, inode counts, supported features, maintenance information, und vieles weitere (Quelle). Sprich, der Superblock ist ein verdammt wichtiges Element zur Interpretation des Dateisystems.
Die Karte ist also so defekt, dass der erste Superblock nicht mehr lesbar ist. Zum Glück hat ein ext4 Dateisystem mehrere Kopien seines Superblocks, also suchen wir die und versuchen es damit mittels fsck erneut. Um die Kopien zu finden machen wir folgendes:
Code:
mke2fs -n /dev/mmcblk0p2
Output:
Code:
mke2fs 1.42.12 (29-Aug-2014)
/dev/mmcblk0p2 contains a ext4 file system
Proceed anyway? (y,n) y
Creating filesystem with 3794688 4k blocks and 950272 inodes
Filesystem UUID: a56c8a06-9907-41a2-86a0-dd601212880b
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208
Wir brauchen auch noch die Block Größe. Der Output zeigt uns eine Größe von 4k, also 4096. Mit einem alternativen Superblock können wir nun erneut fsck starten:
Code:
fsck -b 163840 -B 4096 /dev/mmcblk0p2
wobei -b für den alternativen Superblock steht und -B für die Blockgröße.
So viel hat das leider nicht gebracht. Es kommen lauter Fragen, nach deren Sichtung ich mich entschieden habe alles automatisch reparieren zu lassen:
Code:
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
Superblock has an invalid journal (inode 8).
Clear<y>? yes
*** ext3 journal has been deleted - filesystem is now ext2 only ***
Resize inode not valid. Recreate<y>? yes
Pass 1: Checking inodes, blocks, and sizes
yInode 1 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Root inode has dtime set (probably due to old mke2fs). Fix<y>? yes
Quota inode is not in use, but contains data. Clear<y>? yes
Quota inode is not in use, but contains data. Clear<y>? yes
Inode 5, i_size is 2305843009213693952, should be 0. Fix<y>? yes
Inode 5, i_blocks is 131072, should be 0. Fix<y>? yes
Reserved inode 6 (<The undelete directory inode>) has invalid mode. Clear<y>? yes
Inode 6 has a bad extended attribute block 2064. Clear<y>? yes
Inode 6, i_size is 666532745924706320, should be 0. Fix<y>? yes
Journal inode is not in use, but contains data. Clear<y>? yes
Reserved inode 9 (<Reserved inode 9>) has invalid mode. Clear<y>? yes
Reserved inode 10 (<Reserved inode 10>) has invalid mode. Clear<y>?
Recreate journal<y>? cancelled!
/dev/mmcblk0p2: e2fsck canceled.
/dev/mmcblk0p2: ***** FILE SYSTEM WAS MODIFIED *****
Mittels zusätzlich dem Kommando -y wird alles automatisch mit Ja beantwortet:
Code:
fsck -y -b 163840 -B 4096 /dev/mmcblk0p2
Eine Zeit lang sah das gut aus. Dann kam leider folgendes:
Code:
Error storing directory block information (inode=5542, block=0, num=33754683): Memory allocation failed
/dev/mmcblk0p2: ***** FILE SYSTEM WAS MODIFIED *****
Recreate journal? yes
Creating journal (32768 blocks): Done.
*** journal has been re-created - filesystem is now ext3 again ***
e2fsck: aborted
Nach Recherche im Netz wurde empfohlen folgendes an die Datei /etc/e2fsck.conf mit anzuhängen:
Code:
[scratch_files]
directory = /var/cache/e2fsck
Die man page beschreibt es so:
Code:
[scratch_files]
This stanza controls when e2fsck will attempt to use scratch
files to reduce the need for memory.
Aus einer Mailingliste zu diesem Thema:
Zitat:
This will cause e2fsck to store certain data structures which grow large with backup servers that have a vast number of hard-linked files in /var/cache/e2fsck instead of in memory. This will slow down e2fsck by approximately 25%, but for large filesystems where you couldn't otherwise get e2fsck to complete because you're exhausting the 2GB VM per-process limitation for 32-bit systems, it should allow you to run through to completion.
Man muss den /var/cache/e2fsck Ordner allerdings erst erstellen, bevor man fsck erneut startet:
Code:
mkdir -p /var/cache/e2fsck
Die scratch_files Instanz hat mehrer Optionen, aber eine, die für uns interessant sein könnte: set dirinfo.
Man kann set dirinfo auf false setzen, wenn eine Vielzahl an unterschiedlichen Dateien und nur wenige Ordner vorhanden sind.
Auf Stack Exchange gibt es auch eine gute Erklärung, woher der Out of Memory Fehler herkommen könnte.
Die scratch_files Einstellungen haben bei mir leider nichts gebracht und ich bekomme immer noch den selben Out of Memory Fehler.
Selbst nach dem Rumspielen der dirinfo Einstellungen oder einer angehängten 200 GB Swap Datei gibt er mir immer den selben Fehler.
Außerdem ist dmesg voll mit dieser Art an Logs:
Code:
[12343.5678] end_request: I/O error, dev mmcblk0, sector 50944
Badblocks
Meine letzte Hoffnung war dann Badblocks. Dies ist ein *NIX Dienstprogramm um auf Geräten nach schlechten/kaputten Blöcken zu suchen.
Das folgende Kommando scannt ein Gerät nach bad blocks. Dies ist allerdings eine destructive write operation, d.h. man verliert alle Daten auf dem Gerät/der SD Karte!
Code:
badblocks -o ./badblocks.list -w -s -v -b 4096 -c 16 /dev/mmcblk0
-o um den Output in die Datei ./badblocks.list zu schreiben
-w für den Schreibvorgang
-s um den Prozess anzeigen zu lassen
-v um verbose zu sein
-b 4096 für die Blockgröße 4k
-c 16 um 16 Blöcke auf einmal zu testen (default wären 64)
Es zeigt mir an, dass ein Haufen Schreibvorgänge fehlgeschlagen ist:
Code:
Checking for bad blocks in read-write mode
From block 0 to 3799039
Testing with pattern 0xaa: 0.01% done, 1:57 elapsed. (0/292/0 errors)
^C
Interrupted at block 294
Der Fehler Output meint folgendes:
Code:
number of read errors/number of write errors/number of corruption errors
Also sind die meisten Schreibvorgänge (292 von 294) fehlgeschlagen, was wiederum bedeutet:
Meine SD Karte ist kaputt und kann nicht mehr repariert werden...
Dies ist das worst-case Szenario. Ich habe damit allerdings schon einiges an Hardware reparieren können. Viele schwören noch auf Spinrite, welches ich allerdings nicht besitze und somit nicht testen konnte.
Ich hoffe die Anleitung hilft einigen und ihr habt mehr Glück, falls euch so etwas zustoßen sollte.
