Thema: (Gelöst) - SD-Karte geschrottet?!

Ahoi! - Ich hab schon vor längerer Zeit das Dateisystem einer SD-Karte (1GB) mit SuSE11.2 geschrottet! (- Das war ein Bug, der aber schon gepatcht wurde!-)

Jetzt würde ich diese SD-Karte gern wieder aktivieren. Die Daten auf der Karte sind mir
egal - ich will das Ding nur wieder nutzen können!

Die Karte wird nicht erkannt!

Ich hab jetzt gehöhrt, das man mit "dd" das Ding wieder zum funktioniernen bekommen
kann, weiß aber nicht wie!

Was ergeben denn Sachen wie

Code:

tail -f /var/log/messages

beim einstecken der Karte?
Und was ergibt ein

Code:

/sbin/fdisk -l

nach dem einstecken?

Ich hab das ausprobiert! - fdisk selber scheint zu hängen - das Log hab ich mal gekürzt, weil sich das sowieso immer wiederhohlt!
( - Bis die Karte gezogen wird.) Falls das zur Analyse nicht reicht, sag mir wie lange ich den Test durchführen soll.

Code:

#!-> Ausgabe von /var/log/messeges
#!-> fdisk selbst macht keine Ausgaben!-(

Sep 18 12:17:03 linux-e44q kernel: [  210.700699] sd 0:0:0:1: [sdb] 2012160 512-byte logical blocks: (1.03 GB/982 MiB)
Sep 18 12:17:03 linux-e44q kernel: [  210.702074] sd 0:0:0:1: [sdb] Assuming drive cache: write through
Sep 18 12:17:03 linux-e44q kernel: [  210.705817] sd 0:0:0:1: [sdb] Assuming drive cache: write through
Sep 18 12:17:34 linux-e44q kernel: [  210.705849]  sdb:
Sep 18 12:17:34 linux-e44q kernel: [  241.806045] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:17:59 linux-e44q su: (to root) hiki47 on /dev/pts/2
Sep 18 12:17:59 linux-e44q su: pam_env(su:setcred): non-alphanumeric key 'alias aumix=padsp aumix' in /etc/environment', ignoring
Sep 18 12:17:59 linux-e44q su: pam_env(su:setcred): non-alphanumeric key 'alias sox=padsp sox' in /etc/environment', ignoring
Sep 18 12:17:59 linux-e44q su: pam_env(su:setcred): non-alphanumeric key 'alias timidity=timidity -Oe' in /etc/environment', ignoring
Sep 18 12:18:05 linux-e44q kernel: [  272.806017] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:18:36 linux-e44q kernel: [  303.806016] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:19:07 linux-e44q kernel: [  334.806016] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:19:32 linux-e44q kernel: [  360.332032] INFO: task hald-addon-stor:1510 blocked for more than 120 seconds.
Sep 18 12:19:32 linux-e44q kernel: [  360.332056] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 18 12:19:32 linux-e44q kernel: [  360.332069] hald-addon-st D ffffea0001b5d668     0  1510   1406 0x00000000
Sep 18 12:19:32 linux-e44q kernel: [  360.332084]  ffff88007c8dd858 0000000000000086 ffff88007c8dd7e8 0000000000013a00
Sep 18 12:19:32 linux-e44q kernel: [  360.332099]  0000000000013a00 ffff88007a8b2af8 0000000000013a00 0000000000013a00
Sep 18 12:19:32 linux-e44q kernel: [  360.332114]  0000000000013a00 0000000000013a00 ffff88007a8b2af8 0000000000013a00
Sep 18 12:19:32 linux-e44q kernel: [  360.332128] Call Trace:
Sep 18 12:19:32 linux-e44q kernel: [  360.332152]  [<ffffffff81553c10>] io_schedule+0x70/0xd0
Sep 18 12:19:32 linux-e44q kernel: [  360.332166]  [<ffffffff810fe82d>] sync_page+0x4d/0x80
Sep 18 12:19:32 linux-e44q kernel: [  360.332180]  [<ffffffff810fe8ee>] __lock_page+0x8e/0xd0
Sep 18 12:19:32 linux-e44q kernel: [  360.332193]  [<ffffffff810ffdba>] read_cache_page_async+0xea/0x100
Sep 18 12:19:32 linux-e44q kernel: [  360.332207]  [<ffffffff810ffdec>] read_cache_page+0x1c/0x90
Sep 18 12:19:32 linux-e44q kernel: [  360.332221]  [<ffffffff811bef7e>] read_dev_sector+0x3e/0xd0
Sep 18 12:19:32 linux-e44q kernel: [  360.332235]  [<ffffffff811c4bb5>] read_lba+0xd5/0x120
Sep 18 12:19:32 linux-e44q kernel: [  360.332248]  [<ffffffff811c52de>] find_valid_gpt+0xbe/0x340
Sep 18 12:19:32 linux-e44q kernel: [  360.332261]  [<ffffffff811c55da>] efi_partition+0x7a/0x360
Sep 18 12:19:32 linux-e44q kernel: [  360.332274]  [<ffffffff811bf840>] check_partition+0x120/0x1f0
Sep 18 12:19:32 linux-e44q kernel: [  360.332288]  [<ffffffff811bfa19>] rescan_partitions+0x109/0x350
Sep 18 12:19:32 linux-e44q kernel: [  360.332303]  [<ffffffff811838f7>] __blkdev_get+0x1a7/0x3d0
Sep 18 12:19:32 linux-e44q kernel: [  360.332317]  [<ffffffff81183b3e>] blkdev_get+0x1e/0x40
Sep 18 12:19:32 linux-e44q kernel: [  360.332330]  [<ffffffff81183bdb>] blkdev_open+0x7b/0xf0
Sep 18 12:19:32 linux-e44q kernel: [  360.332343]  [<ffffffff81149ba5>] __dentry_open+0x135/0x370
Sep 18 12:19:32 linux-e44q kernel: [  360.332357]  [<ffffffff81149f1f>] nameidata_to_filp+0x6f/0x80
Sep 18 12:19:32 linux-e44q kernel: [  360.332371]  [<ffffffff8115b81a>] do_filp_open+0x2ea/0xb40
Sep 18 12:19:32 linux-e44q kernel: [  360.332384]  [<ffffffff811498c3>] do_sys_open+0x73/0x150
Sep 18 12:19:32 linux-e44q kernel: [  360.332397]  [<ffffffff81149a0e>] sys_open+0x2e/0x50
Sep 18 12:19:32 linux-e44q kernel: [  360.332411]  [<ffffffff8100c682>] system_call_fastpath+0x16/0x1b
Sep 18 12:19:32 linux-e44q kernel: [  360.332446]  [<00007f8d503f3390>] 0x7f8d503f3390
Sep 18 12:19:38 linux-e44q kernel: [  365.808425] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:20:09 linux-e44q kernel: [  396.806017] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:20:09 linux-e44q kernel: [  397.202725] sd 0:0:0:1: [sdb] Unhandled error code
Sep 18 12:20:09 linux-e44q kernel: [  397.202748] sd 0:0:0:1: [sdb] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK
Sep 18 12:20:09 linux-e44q kernel: [  397.202759] end_request: I/O error, dev sdb, sector 0
Sep 18 12:20:09 linux-e44q kernel: [  397.202769] __ratelimit: 6 callbacks suppressed
Sep 18 12:20:09 linux-e44q kernel: [  397.202778] Buffer I/O error on device sdb, logical block 0
Sep 18 12:20:40 linux-e44q kernel: [  427.806016] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:21:11 linux-e44q kernel: [  458.806017] usb 1-1: reset high speed USB device using ehci_hcd and address 2
Sep 18 12:21:32 linux-e44q kernel: [  480.332052] INFO: task fdisk:7103 blocked for more than 120 seconds.
Sep 18 12:21:32 linux-e44q kernel: [  480.332073] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 18 12:21:32 linux-e44q kernel: [  480.332083] fdisk         D 0000000000000000     0  7103   7080 0x00000000
Sep 18 12:21:32 linux-e44q kernel: [  480.332096]  ffff88007d51fbb8 0000000000000086 ffff88007d51fb48 0000000000013a00
Sep 18 12:21:32 linux-e44q kernel: [  480.332109]  0000000000013a00 ffff88006c514438 0000000000013a00 0000000000013a00
Sep 18 12:21:32 linux-e44q kernel: [  480.332121]  0000000000013a00 0000000000013a00 ffff88006c514438 0000000000013a00
Sep 18 12:21:32 linux-e44q kernel: [  480.332133] Call Trace:
Sep 18 12:21:32 linux-e44q kernel: [  480.332156]  [<ffffffff81554ae8>] __mutex_lock_slowpath+0x118/0x200
Sep 18 12:21:32 linux-e44q kernel: [  480.332170]  [<ffffffff8155458c>] mutex_lock+0x2c/0x60
Sep 18 12:21:32 linux-e44q kernel: [  480.332184]  [<ffffffff81183798>] __blkdev_get+0x48/0x3d0
Sep 18 12:21:32 linux-e44q kernel: [  480.332197]  [<ffffffff81183b3e>] blkdev_get+0x1e/0x40
Sep 18 12:21:32 linux-e44q kernel: [  480.332208]  [<ffffffff81183bdb>] blkdev_open+0x7b/0xf0
Sep 18 12:21:32 linux-e44q kernel: [  480.332220]  [<ffffffff81149ba5>] __dentry_open+0x135/0x370
Sep 18 12:21:32 linux-e44q kernel: [  480.332232]  [<ffffffff81149f1f>] nameidata_to_filp+0x6f/0x80
Sep 18 12:21:32 linux-e44q kernel: [  480.332244]  [<ffffffff8115b81a>] do_filp_open+0x2ea/0xb40
Sep 18 12:21:32 linux-e44q kernel: [  480.332256]  [<ffffffff811498c3>] do_sys_open+0x73/0x150
Sep 18 12:21:32 linux-e44q kernel: [  480.332267]  [<ffffffff81149a0e>] sys_open+0x2e/0x50
Sep 18 12:21:32 linux-e44q kernel: [  480.332279]  [<ffffffff8100c682>] system_call_fastpath+0x16/0x1b
Sep 18 12:21:32 linux-e44q kernel: [  480.332313]  [<00007fd7b4dd26f0>] 0x7fd7b4dd26f0
Sep 18 12:21:42 linux-e44q kernel: [  489.806017] usb 1-1: reset high speed USB device using ehci_hcd and address 2

Zitat von mzn5

fdisk selber scheint zu hängen

Wie meinst Du das?
Hast Du auch definitiv

Code:

/sbin/fdisk -l

eingegeben?

Jedenfalls laesst das hier nichts gutes hoffen:

Code:

[...]
end_request: I/O error, dev sdb, sector 0
[...]
Buffer I/O error on device sdb, logical block 0
[...]

Zitat von glako

Jedenfalls laesst das hier nichts gutes hoffen:

Code:

[...]
end_request: I/O error, dev sdb, sector 0
[...]
Buffer I/O error on device sdb, logical block 0
[...]

+1

Da ist definitiv mehr als nur "ein Dateisystem geschrottet", das sieht verdächtig nach defekter Hardware aus.

Greetz,

RM

Ja ich hab "fdisk -l" gestartet. - Ist aber wohl mangels Möglichkeiten
hängen geblieben! - Bis ich die Karte gezogen hab.
Im MessageLOG steht auch irgend wo die Zeile:

INFO: task fdisk:7103 blocked for more than 120 seconds.

Um noch mal auf meinen ersten Lösungsvorschlag zurück zu kommen
- ich hab gehöhrt, dass man mit "dd" mittels direktem Hardwarezugriffs
Dateien auf einen Datenträger schreiben kann. So sollte:

dd if=/dev/zero of=/dev/sdb bs=1M count=1024

mir eine mit Nullen gefüllte 1GB-Datei, mit Blockgrösse 1M,
auf meine SD-Karte schreiben (so stand's jedenfalls in der Anleitung)!
-> Da müsste dann das Gleiche rauskommen, wie wenn ich mittels
Diskeditor alle Blöcke mit Nullen überschreibe!?

Meine Frage: Muss ich bezüglich SD-Karte oder Programverständnis
noch war beachten? - z.B: Ob bs=512k nicht besser wäre?

Zitat von mzn5

Meine Frage: Muss ich bezüglich SD-Karte oder Programverständnis
noch war beachten?

Eigentlich nur, daß man sich auch 100%ig sicher ist auf das richtige device zu schreiben und nicht z.B. auf einen zuvor angestöpselten USB-Stick, der dann /dev/sdb sein könnte.

Zitat von mzn5

- z.B: Ob bs=512k nicht besser wäre?

*Kicher*

Das ist beim Überschreiben mit _Nullen_ wirklich sowas von egal, eigentlich ist das schon "egaler".

Und sollten die Ausgaben des Systemlogs in etwa das bedeuten, was nicht nur meine Wenigkeit sondern auch glako schon angesprochen haben, dann ist es sogar "am egalsten", aber das wirst Du dann schon merken.

Ich hab den dd-Befehl jetzt mal ausgeführt. - Hat aber nix gebracht. - Warscheinlich doch ein Hardwarefehler. Danke für die moralische Unterstützung. Ich schmeiss das Ding jetzt doch weg.

Zitat von mzn5

Ich hab den dd-Befehl jetzt mal ausgeführt. - Hat aber nix gebracht.

Anhand der I/O-Fehler, die das Ding ausgeworfen hat, nicht wirklich eine Überraschung, dd bricht bei Lese-/Schreibfehlern ab und wenn man mal genau hinsieht

Code:

[...]
end_request: I/O error, dev sdb, sector 0
[...]
Buffer I/O error on device sdb, logical block 0
[...]

dann dürfte das sogar sehr schnell passiert sein.

Zitat von mzn5

- Warscheinlich doch ein Hardwarefehler.

Sehr wahrscheinlich sogar, allgemein hat Flashspeicher (also auch USB-Sticks) eine beschränkte Lebenszeit und bevor jetzt jemand mit "dd_rescue" oder Ähnlichem ankommt, einem Speichermedium, das solche Fehler auswirft, würde ich KEINE Daten mehr anvertrauen, vor allem nicht einer SD-Karte, die nur ein paar Euro kostet.

Zitat von mzn5

Danke für die moralische Unterstützung. Ich schmeiss das Ding jetzt doch weg.

Das ist mit Sicherheit -oder soll man sagen "mit Datensicherheit"? (pun intended)- die beste Entscheidung.

Ich mache dann mal das Licht aus.

Greetz,

RM