Plattenfehler mit Ubuntu 12.04

[Uhu U. (uhu)]

Mitten im Betrieb ist mein 12.04 plötzlich hängen geblieben - der 
Mauszeiger ließ sich noch bewegen, aber das wars dann auch.

Nach einem Reset wurde noch das Luks-Paßwort abgefragt und dann blieb er 
in der Ram-Disk hängen. Das Verhalten ist reproduzierbar.

Als nächstes habe ich auf die 10.04-Platte umgeschaltet und gebootet. 
Ein Versuch, die 12.04-Platte zu mounten scheitert nach Abfrage des 
Luks-Paßwortes mit der Fehlermeldung im Anhang.

dmesg zeigt folgende Meldungen dazu:

[  497.535837] ata2.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[  497.535843] ata2.01: failed command: READ DMA EXT
[  497.535849] ata2.01: cmd 25/00:f8:80:35:cd/00:00:1c:00:00/f0 tag 0 dma 126976 in
[  497.535850]          res 51/40:00:3a:36:cd/40:00:1c:00:00/f0 Emask 0x9 (media error)
[  497.535854] ata2.01: status: { DRDY ERR }
[  497.535856] ata2.01: error: { UNC }
[  497.591683] ata2.01: configured for UDMA/133
[  497.591713] sd 1:0:1:0: [sdb] Unhandled sense code
[  497.591715] sd 1:0:1:0: [sdb] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[  497.591719] sd 1:0:1:0: [sdb] Sense Key : Medium Error [current] [descriptor]
[  497.591723] Descriptor sense data with sense descriptors (in hex):
[  497.591726]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[  497.591735]         1c cd 36 3a 
[  497.591739] sd 1:0:1:0: [sdb] Add. Sense: Unrecovered read error - auto reallocate failed
[  497.591744] sd 1:0:1:0: [sdb] CDB: Read(10): 28 00 1c cd 35 80 00 00 f8 00
[  497.591753] end_request: I/O error, dev sdb, sector 483210810
[  497.591790] ata2: EH complete
[  497.592832] JBD: Failed to read block at offset 12183
[  497.592837] JBD: recovery failed
[  497.592839] EXT4-fs (dm-4): error loading journal

Das sieht überhaupt nicht schön aus... Jetzt fragt sich natürlich, wie 
und ob ich die Platte wieder flott bekommen kann.

Hat jemand eine Idee?

[Guido C. (guidoanalog)]

Hallo,

ich würde zuerst einmal die S.M.A.R.T Parameter der Festplatte auslesen. 
So bekommst Du einen ersten Eindruck, ob Du es mit einem Software oder 
Hardwareproblem zu tun hast. Unter Windows verwende ich hierfür die 
Portable Edition von CrystalDiskInfo.

Das SATA-Kabel hast Du vermutlich schon einmal abgezogen und wieder 
aufgesteckt? Wirkt manchmal wunder.

Mit freundlichen Grüßen
Guido

[Uhu U. (uhu)]

Es scheint ein kaputter Sektor im ext4-Journal zu sein.

Ich habe jetzt mal ein /cp /dev/mapper/lx6-root /dev/null/ angekickt - 
er liest wacker...

Versuche, das mapper-Device als ext2 zu mounten scheitern.

SMART zeigt keine Fehler.

[Uhu U. (uhu)]

Das cp /dev/mapper/lx6-root /dev/null habe ich abgebrochen und 
stattdessen ein cp /dev/sdb /dev/null laufen gelassen. Das stürzt mit 
derselben Sektornummer ab, wie der Mountversuch. dmesg-Ausgabe im 
Anhang.

[Uhu U. (uhu)]

Ein beherztes sudo fsck /dev/mapper/lx6-root hats wieder grade gebogen, 
die Platte läßt sich unter 10.04 wieder mounten. Es kam eine Latte 
Meldungen und ich hoffe, die 12.04 läßt sich auch wieder booten:

$ sudo fsck /dev/mapper/lx6-root
fsck from util-linux-ng 2.17.2
e2fsck 1.41.11 (14-Mar-2010)
/dev/mapper/lx6-root: recovering journal
Error reading block 60338071 (Attempt to read block from filesystem resulted in short read).  Ignore error<y>? yes

Force rewrite<y>? yes

Clearing orphaned inode 28970296 (uid=1000, gid=1000, mode=0100600, size=25128385)
<63 weitere...>
Clearing orphaned inode 28966925 (uid=120, gid=132, mode=0100600, size=0)
Clearing orphaned inode 28966924 (uid=120, gid=132, mode=0100600, size=0)
/dev/mapper/lx6-root: clean, 694209/30244864 files, 91105702/120972288 blocks

[Uhu U. (uhu)]

Die Möhre läuft wieder...

[Klaus W. (mfgkw)]

ausgeschaltet, ohne zu umounten?

[Christian B. (casandro)]

Du das ist wirklich ein defekter Sektor auf der Platte.
Du kannst ja badblock im Lesen-Modus laufen lassen, wenn das dann auch 
einen Fehler aus gibt, schmeiß die Platte weg.

[c. m. (Gast)]

Uhu Uhuhu schrieb:
> Die Möhre läuft wieder...

lass zur sicherheit mal einen selbsttest über die platte laufen.
aus dem package "smartmontools" (o.ä. kann sein das es in deiner distri 
anders heißt)

smartctl --test=long /dev/sdb

wenn der selftest fertig ist (läuft im hintergrund), so nach einer bis 
einigen stunden, kannst du mit

smartctl --all /dev/sdb

schauen obs unbehebbare probleme gibt und du dir eine neue platte 
besorgen solltest. backup hast du, oder?


Klaus Wachtler schrieb:
> ausgeschaltet, ohne zu umounten?

das ist dem device copy egal. das versucht nicht das möglicherweise 
fehlerhafte dateisystem zu lesen sondern die sektoren der platte (wobei 
ein dd oder dd_rescue schöner gewesen wäre - bei "cp /dev/sdb" rollen 
sich mir die fußnägel :)

[Mike J. (emjey)]

@  Uhu Uhuhu (uhu)
So erstelle ich mein komprimiertes Backup.

Beim der Home-Partition wäre der Copy Befehl vielleicht besser gewesen 
als die ganze Partition zu sichern. Da die leeren Bereiche nicht 
wirklich leer sind wurde die 25 GByte Partition, bei der nur 900MByte 
belegt sind auf 2.5 GByte komprimiert. (das ausnullen des freien 
Bereichs würde somit Speicherplatz im Image sparen, ist aber 
komplizierter)

Partition Backup erstellen:
sudo dd if=/dev/sdb1 bs=1M | gzip -4 > /home/mike/System/backup/backup_sdb1_root_2012-08-11.img.gz

sudo dd if=/dev/sdb3 bs=1M | gzip -4 > /home/mike/System/backup/backup_sdb3_home_2012-08-11.img.gz

Beim erstellen des Backups den fortschritt ausgeben lassen (dd hat hier die PrizessID 2358):
while [ "`ps -a | grep 2358`" ]; do sudo kill -SIGUSR1 2358; sleep 10; done 

Partition Backup zurueck spielen:
sudo gunzip -c /home/mike/System/backup/backup_sdb1_root_2012-08-11.img.gz | dd of=/dev/sda1 bs=1M

[Uhu U. (uhu)]

Klaus Wachtler schrieb:
> ausgeschaltet, ohne zu umounten?

Wenn die Kiste hängt, kann man das schlecht. Außer dem Mauszeiger hat 
sich nichts bewegt und Plattenaktivitäten konnte man zumindest keine 
sehen, als ich reset gedrückt habe.

c. m. schrieb:
> bei "cp /dev/sdb" rollen sich mir die fußnägel :)

Wieso? ich habe den Beweis bekommen, daß die Platte prinzipiell noch 
funktioniert. Was hinter dem defekten Sektor los ist, bekommt man damit 
natürlich nicht raus, aber eine erste Aussage über die Sektoren davor 
bekommt man.

Christian Berger schrieb:
> Du kannst ja badblock im Lesen-Modus laufen lassen, wenn das dann auch
> einen Fehler aus gibt, schmeiß die Platte weg.

Wegen einem defekten Sektor auf einer 500 GB Platte wäre das etwas 
übertrieben. Das Thema steht erst an, wenn sich solche Fisimatenden 
wiederholen.

Mike J. schrieb:
> So erstelle ich mein komprimiertes Backup.

Datensicherung mache ich mit rdiff-backup. Das ist sowas ähnliches, wie 
svn & Co. für Dateisysteme: der aktuelle Stand ist direkt zugreifbar, 
für die älteren Versionen werden reverse deltas gespeichert.


SMART zeigt interessanterweise einen einzigen Lesefehler, keinen 
Schreibfehler und keine Reallokationen an. Ebenso keine unbehebbaren 
Fehler.

Laufzeit ist laut SMART ~5700 Stunden.

[Klaus W. (mfgkw)]

Uhu Uhuhu schrieb:
> Klaus Wachtler schrieb:
>> ausgeschaltet, ohne zu umounten?
>
> Wenn die Kiste hängt, kann man das schlecht. Außer dem Mauszeiger hat
> sich nichts bewegt und Plattenaktivitäten konnte man zumindest keine
> sehen, als ich reset gedrückt habe.

War ja kein Vorwurf, aber nach meiner Erfahrung ein nicht seltener 
Grund.
Hatte aber dabei nicht auf dem Schirm, daß das sektorweise Kopieren ja 
auch scheiterte. Damit ist es natürlich ein HW-Problem.

Es gibt übrigens eine Spezialversion von dd (dd-rescue), die bei Fehlern 
einzelner Sektoren nicht kleinlich ist und wenigstens den Rest dahinter 
kopiert.
Damit kann man gelegentlich noch etwas retten, wenn man auf die Kopie 
dann ein fsck los lässt.

[Mike J. (emjey)]

Das hatte ich auch mal, Linux fährt hoch und der Bildschirm bleibt 
schwarz, ich konnte nichts sehen und nicht in auf eine Konsole 
umschalten.
Man konnte den Power Knopf drücken, es gab etwas Festplattenaktivität 
und ist dann sauber runtergefahren.

rdiff-backup schau ich mir mal an.

[Uhu U. (uhu)]

badblocks im Lesemodus hat nichts gefunden, die SMART-Fehlerdaten haben 
sich nicht geändert. Das war wohl ein behebbarer Sektorfehler.

[Norbert (Gast)]

Uhu Uhuhu schrieb:
> badblocks im Lesemodus hat nichts gefunden, die SMART-Fehlerdaten haben
> sich nicht geändert. Das war wohl ein behebbarer Sektorfehler.

Wenn du ein komplettes Backup hast und die Maschine evtl per LIVE System 
booten kannst, empfehle ich wärmstens badblocks im non-destructive write 
mode durchlaufen zu lassen.
'man 8 badblocks' kennt die Parameter.

Damit bleiben die Daten erhalten und die komplette Plattenoberfläche(n) 
wird einmal 'magnetisch durchgeknetet'.
Wirkt wie eine Frischzellenkur und erlaubt der eingebauten 
Festplattenlogik auch Sektoren zu erkennen, die zwar (gerade) noch 
lesbar sind aber vielleicht schon beim nächsten Schreiben Probleme 
verursachen könnten. Damit können sie problemlos reallokiert/'umgemappt' 
werden.

[Uhu U. (uhu)]

Das habe ich von nicht all zu langer Zeit schonmal gemacht, bevor ich 
das 12.04 drauf gezogen habe.

Ich habe jetzt mal den ausführlichen SMART-Test angeworfen.

[oszi40 (Gast)]

Uhu Uhuhu schrieb:
> Ich habe jetzt mal den ausführlichen SMART-Test angeworfen.

NUR vom Testen ist noch keine HD gesünder geworden. In ungünstigen 
Fällen ist diese HD in wenigen Stunden ganz krank. Davor solltest Du die 
wichtigen Ordner gesichert haben.

[Uhu U. (uhu)]

So, kranker ist sie sie durch den Test nicht geworden, denn sie ist 
kerngesund.

[Mike J. (emjey)]

Ich hatte ein paar mal den Fall (bei verschiedenen PCs) dass die 
Festplatte kurz ausgesetzt hat, dabei noch kurz irgend einen Mist 
geschrieben hat und dann weiter lief, man konnte Windows nicht mehr 
bedienen.

Nach einem Neustart gab es dann irgend welche Fehler, die Festplatte 
wurde mit Scandisk überprüft und etwas wieder her gestellt.

Der Grund lag hier immer an einem ausgenuddelten Stecker (nicht die 
S-ATA Stromstecker die sind scheinbar besser) vom Netzteil, da saß ein 
Kontakt etwas locker.

Das bedeutet: Hoher Kontaktwiderstand + bei geringen Vibrationen der 
Lüfter muss sich da etwas verändert haben.

Inzwischen hab ich dort andere Steckkontakte verwendet. (Kabel an der 
Festplatte angelötet)