Hallo Forum,
aktuell geht es bei mir um eine defekte(?) µSD-Card. Vorab: die Daten
darauf interessieren mich nicht. Ich würde nur gerne verstehen was da
vor sich geht.
Aktuell finden sich auf der Karte Daten von einer Raspbian-Installation,
sie war also höchstwahrscheinlich mal in einem Raspberry Pi eingesetzt.
Jetzt habe ich diese Karte bei mir in der Schublade gefunden und wollte
sie neu nutzen.
Also die Windows-Formatierung drüberlaufen lassen. Ging nicht. Okay, ist
Windows, kann sein, dass es mit Linux besser geht.
Also ein Linux (Arch Linux auf aktuellstem Stand) gebootet und die
folgenden Befehle eingegeben: 1 | /run/media/username/boot $ ls -l
| 2 | total 19888
| 3 | -rw-r--r-- 1 username users 18693 Aug 21 2015 COPYING.linux
| 4 | -rw-r--r-- 1 username users 1494 Nov 18 2015 LICENCE.broadcom
| 5 | -rw-r--r-- 1 username users 18974 Mar 18 2016 LICENSE.oracle
| 6 | -rw-r--r-- 1 username users 11104 Mar 14 2016 bcm2708-rpi-b-plus.dtb
| 7 | -rw-r--r-- 1 username users 10825 Mar 14 2016 bcm2708-rpi-b.dtb
| 8 | -rw-r--r-- 1 username users 10855 Mar 14 2016 bcm2708-rpi-cm.dtb
| 9 | -rw-r--r-- 1 username users 12092 Mar 14 2016 bcm2709-rpi-2-b.dtb
| 10 | -rw-r--r-- 1 username users 12866 Mar 16 2016 bcm2710-rpi-3-b.dtb
| 11 | -rw-r--r-- 1 username users 17920 Feb 9 2016 bootcode.bin
| 12 | -rw-r--r-- 1 username users 136 Mar 18 2016 cmdline.txt
| 13 | -rw-r--r-- 1 username users 1635 Mar 18 2016 config.txt
| 14 | -rw-r--r-- 1 username users 6466 Mar 16 2016 fixup.dat
| 15 | -rw-r--r-- 1 username users 2496 Mar 16 2016 fixup_cd.dat
| 16 | -rw-r--r-- 1 username users 9709 Mar 16 2016 fixup_db.dat
| 17 | -rw-r--r-- 1 username users 9717 Mar 16 2016 fixup_x.dat
| 18 | -rw-r--r-- 1 username users 103 Mar 18 2016 issue.txt
| 19 | -rw-r--r-- 1 username users 3964404 Mar 16 2016 kernel.img
| 20 | -rw-r--r-- 1 username users 4055172 Mar 16 2016 kernel7.img
| 21 | drwxr-xr-x 2 username users 8192 Mar 18 2016 overlays
| 22 | -rw-r--r-- 1 username users 2740920 Mar 16 2016 start.elf
| 23 | -rw-r--r-- 1 username users 613624 Mar 16 2016 start_cd.elf
| 24 | -rw-r--r-- 1 username users 4889352 Mar 16 2016 start_db.elf
| 25 | -rw-r--r-- 1 username users 3841544 Mar 16 2016 start_x.elf
| 26 |
| 27 | /run/media/username/boot $ rm -rf *
| 28 | # es kommt keine Fehlermeldung
| 29 | /run/media/username/boot $ ls -l
| 30 | # selber output wie oben, es wurden also keine Dateien gelöscht.
| 31 | /run/media/username/boot $ rm -rfv *
| 32 | removed 'COPYING.linux'
| 33 | removed 'LICENCE.broadcom'
| 34 | removed 'LICENSE.oracle'
| 35 | removed 'bcm2708-rpi-b-plus.dtb'
| 36 | # removed-meldung für jede Datei, aber die Dateien bleiben immernoch da
|
Also habe ich probiert, die ganze Karte auszunullen: 1 | $ sudo dd if=/dev/null of=/dev/mmcblk0
| 2 | 0+0 records in
| 3 | 0+0 records out
| 4 | 0 bytes copied, 3.1531e-05 s, 0.0 kB/s
| 5 | # die Dateien sind immernoch da, kein Wunder, es wurde ja nichts geschrieben
|
Jetzt wollte ich es doch mal probieren: mittels gdisk formatieren 1 | $ sudo gdisk /dev/mmcblk0
| 2 | GPT fdisk (gdisk) version 1.0.3
| 3 |
| 4 | Partition table scan:
| 5 | MBR: MBR only
| 6 | BSD: not present
| 7 | APM: not present
| 8 | GPT: not present
| 9 |
| 10 |
| 11 | ***************************************************************
| 12 | Found invalid GPT and valid MBR; converting MBR to GPT format
| 13 | in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
| 14 | typing 'q' if you don't want to convert your MBR partitions
| 15 | to GPT format!
| 16 | ***************************************************************
| 17 |
| 18 |
| 19 | Command (? for help): o
| 20 | This option deletes all partitions and creates a new protective MBR.
| 21 | Proceed? (Y/N): Y
| 22 |
| 23 | Command (? for help): p
| 24 | Disk /dev/mmcblk0: 15523840 sectors, 7.4 GiB
| 25 | Sector size (logical/physical): 512/512 bytes
| 26 | Disk identifier (GUID): 01FA3D34-52D0-4AA6-9CC4-49567D5B3D5A
| 27 | Partition table holds up to 128 entries
| 28 | Main partition table begins at sector 2 and ends at sector 33
| 29 | First usable sector is 34, last usable sector is 15523806
| 30 | Partitions will be aligned on 2048-sector boundaries
| 31 | Total free space is 15523773 sectors (7.4 GiB)
| 32 |
| 33 | Number Start (sector) End (sector) Size Code Name
| 34 |
| 35 | Command (? for help): n
| 36 | Partition number (1-128, default 1):
| 37 | First sector (34-15523806, default = 2048) or {+-}size{KMGTP}:
| 38 | Last sector (2048-15523806, default = 15523806) or {+-}size{KMGTP}:
| 39 | Current type is 'Linux filesystem'
| 40 | Hex code or GUID (L to show codes, Enter = 8300):
| 41 | Changed type of partition to 'Linux filesystem'
| 42 |
| 43 | Command (? for help): w
| 44 |
| 45 | Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
| 46 | PARTITIONS!!
| 47 |
| 48 | Do you want to proceed? (Y/N): Y
| 49 | OK; writing new GUID partition table (GPT) to /dev/mmcblk0.
| 50 | Warning: The kernel is still using the old partition table.
| 51 | The new table will be used at the next reboot or after you
| 52 | run partprobe(8) or kpartx(8)
| 53 | The operation has completed successfully.
|
Und natürlich sind die alten Partitionen noch da, mitsamt allen Dateien.
Was mich halt wundert ist, dass keine Fehler gemeldet werden. Ist evtl.
einfach der Controller der SD-Karte hin?
Ich habe es sowohl mit dem eingebauten µSD-Slot am Laptop, als auch
einem externen µSD-Adapter probiert, bei beidem genau das gleiche
Verhalten. Es wurde also kein µSD-SD-Adaper genutzt, der ein Write-Lock
besitzt (außer es gäbe ein soft-writelock, das ich allerdings nicht
bewusste gesetzt hätte).
Hat jemand eine Ahnung, was man außer wegwerfen noch tun könnte?
Mit freundlichen Grüßen,
N.G.
N. G. schrieb:
> Also die Windows-Formatierung drüberlaufen lassen.
Hast Du mal den offiziellen SD-Formatter ausprobiert?
https://www.sdcard.org/downloads/formatter_4/
N. G. schrieb:
> Hat jemand eine Ahnung, was man außer wegwerfen noch tun könnte?
Vorher mit dem Hammer zerkleinern.
Sei froh dass die Daten noch lesbar sind, oftmals geben SD Karten gleich
ganz auf.
N. G. schrieb:
> $ sudo dd if=/dev/null of=/dev/mmcblk0
> 0+0 records in
> 0+0 records out
> 0 bytes copied, 3.1531e-05 s, 0.0 kB/s
> # die Dateien sind immernoch da, kein Wunder, es wurde ja nichts
> geschrieben
Dann sollten in dmesg aber Fehlermeldungen auftauchen. Das dd Kommando
bricht so schnell nur bei Fehlern ab.
Hilft Dir aber alles nix, der Flash ist so kaputt das das Wear Leveling
nicht mehr tut.
Was steht eigentlich im Systemlog (dmesg) wenn du die Karte steckst?
Eventuell blockiert der Treiber die Schreibvorgänge?
Hallo an alle,
Rufus Τ. F. schrieb:
> Hast Du mal den offiziellen SD-Formatter ausprobiert?
Nein, mach ich gleich mal. Muss nur wieder auf windows wechseln :)
Jim M. schrieb:
> N. G. schrieb:
>> Hat jemand eine Ahnung, was man außer wegwerfen noch tun könnte?
>
> Vorher mit dem Hammer zerkleinern.
Naja, die Daten sind wie gesagt völlig egal.
Jim M. schrieb:
> N. G. schrieb:
>> $ sudo dd if=/dev/null of=/dev/mmcblk0
>> 0+0 records in
>> 0+0 records out
>> 0 bytes copied, 3.1531e-05 s, 0.0 kB/s
>> # die Dateien sind immernoch da, kein Wunder, es wurde ja nichts
>> geschrieben
>
> Dann sollten in dmesg aber Fehlermeldungen auftauchen. Das dd Kommando
> bricht so schnell nur bei Fehlern ab.
Das ist genau das, was mich wundert. Es gibt eben keinen Fehler.
> Hilft Dir aber alles nix, der Flash ist so kaputt das das Wear Leveling
> nicht mehr tut.
Ja, irgendetwas in der Richtung vermute ich auch.
Markus -. schrieb:
> Was steht eigentlich im Systemlog (dmesg) wenn du die Karte steckst?
>
> Eventuell blockiert der Treiber die Schreibvorgänge?
1 | $ dmesg
| 2 | [ 3975.128436] FAT-fs (mmcblk0p1): unable to read boot sector to mark fs as dirty
| 3 | [ 3976.233688] mmc0: new high speed SDHC card at address aaaa
| 4 | [ 3976.235614] mmcblk0: mmc0:aaaa SU08G 7.40 GiB
| 5 | [ 3976.242107] mmcblk0: p1 p2
|
Was mir auffällt ist die Adresse "aaaa", die klingt irgendiwe seltsam.
Aber um ehrlich zu sein: keine Ahnung.
Aber danke schon mal für eure Antworten!
N. G. schrieb:
> Rufus Τ. F. schrieb:
>> Hast Du mal den offiziellen SD-Formatter ausprobiert?
> Nein, mach ich gleich mal. Muss nur wieder auf windows wechseln :)
Okay, interessant:
- Quick Format: "Formatting was successfully completeted."
- Overwrite Format: "Formatting failed"
Wie schon was erwartet zeigt sich in beiden Fällen wieder keine
Änderung.
Hat noch jemand Ideen?
ein Smartphone hat mir schon 2 MicroSD Karten auf diese Art gekillt. Die
Erste war eine ganz billige NoName und da dachte ich es läge an der
Karte, also mal eine Sandisk-Karte reingetan und nach einem halben Jahr
war auch diese Karte ausschliesslich lesbar. Es kann weder was
geschrieben, noch gelöscht werden. Ich hab sämtliche Tipps aus vielen
Foren durchprobiert, sowohl unter Linux als auch unter Windows. Es half
nix. Einige der empfohlenen Linux-Tools haben auch irgendwelche
kryptischen Fehler gemeldet. Einige boten dafür sogar an den Fehler zu
beheben aber nach der Ausführung hat sich auf der Karte so garnix
geändert. Ich hab die Dinger geshreddert und entsorgt.
Jim M. schrieb:
>> $ sudo dd if=/dev/null of=/dev/mmcblk0
>> 0+0 records in
>> 0+0 records out
>> 0 bytes copied, 3.1531e-05 s, 0.0 kB/s
>> # die Dateien sind immernoch da, kein Wunder, es wurde ja nichts
>> geschrieben
>
> Dann sollten in dmesg aber Fehlermeldungen auftauchen. Das dd Kommando
> bricht so schnell nur bei Fehlern ab.
Nein. Wenn du von /dev/null kopierst, dann bekommt dd sofort
eingangsseitig ein EOF und ist zufrieden. Was der TO wollte, war von
/dev/zero kopieren.
> Hilft Dir aber alles nix, der Flash ist so kaputt das das Wear Leveling
> nicht mehr tut.
Vermutlich ist vom Flash einfach nur der /WR-Pin abgerissen, so dass
Schreibzugriffe kommentarlos ignoriert werden.
Hallo, irgendwie habe ich es geschafft den Beitrag zu übersehen...
S. R. schrieb:
> Nein. Wenn du von /dev/null kopierst, dann bekommt dd sofort
> eingangsseitig ein EOF und ist zufrieden. Was der TO wollte, war von
> /dev/zero kopieren.
Ups, das is mir jetzt auch noch nie passiert. Hier das ganze mit dem
richtigen /dev/zero-Device: 1 | $ sudo dd if=/dev/zero of=/dev/mmcblk0 bs=4M status=progress
| 2 | 7948206080 bytes (7.9 GB, 7.4 GiB) copied, 2995 s, 2.7 MB/s
| 3 | dd: error writing '/dev/mmcblk0': No space left on device
| 4 | 1896+0 records in
| 5 | 1895+0 records out
| 6 | 7948206080 bytes (7.9 GB, 7.4 GiB) copied, 3085.94 s, 2.6 MB/s
|
Natürlich keine Änderung...
>
>> Hilft Dir aber alles nix, der Flash ist so kaputt das das Wear Leveling
>> nicht mehr tut.
>
> Vermutlich ist vom Flash einfach nur der /WR-Pin abgerissen, so dass
> Schreibzugriffe kommentarlos ignoriert werden.
Bei einer normalen SD-Karte könnte ich mir das ja noch vorstellen, aber
bei einer (voll-vergossenen?) microSD?
Evtl. hat noch jemand eine Idee, was für Untersuchungen man mit der
Karte noch anstellen kann.
Mfg
N.G.
N. G. schrieb:
>> Vermutlich ist vom Flash einfach nur der /WR-Pin abgerissen, so dass
>> Schreibzugriffe kommentarlos ignoriert werden.
>
> Bei einer normalen SD-Karte könnte ich mir das ja noch vorstellen, aber
> bei einer (voll-vergossenen?) microSD?
Wieso vollvergossen? Da kleben trotzdem BGA-Bausteine auf einer Platine,
Flash und Controller brav getrennt. Dreimal schief angefasst und
gebogen, dazu noch schlecht verlötet (chinesische Nachtschicht) und der
Pin ist ab.
Muss ja nicht der Pin am Flash (oder Controller) sein. Vielleicht ist
das eine Sicherheitsschaltung (Selbsttest fehlgeschlagen) und der
Controller merkt's nicht, ein Fehler im Controller oder was ganz
anderes.
Ich würde in den nächsten Supermarkt gehen und mir dort eine neue Karte
besorgen. Mit dieser ist kein Spaß mehr zu haben, also brich das Gehäuse
auf und schaue nach, ob sie tatsächlich vollvergossen war oder nicht.
:-)
S. R. schrieb:
> Wieso vollvergossen? Da kleben trotzdem BGA-Bausteine auf einer Platine,
In einer Micro-SD? Nein. Da sind nackte Chips auf ein
Leiterplattensubstrat gebondet, und das komplett vergossen. Das Resultat
ist die SD-Karte.
Ein "/WR"-Pin kann es unabhängig von der Bauform nicht sein, weil die
verwendeten Flash-Bausteine ein etwas anderes Interface verwenden, als
die klassischen JEDEC- bzw. EPROM-kompatiblen NOR-Flashes.
Bei den hier üblichen hochintegrierten NAND-Flashes gibt es (vereinfacht
betrachtet) nur ein Kommando- und ein Datenregister, und das
Kommandoregister muss für jede Operation, Lesen, Schreiben, Löschen etc.
beschrieben werden können - wofür eine /WR-Leitung dringend nötig ist.
Danke für den Hinweis. Dann ist die SD-Karte also "einfach nur so"
kaputt, oder er hat sie irgendwie in einen Schreibschutzmodus
geschaltet.
Hallo,
ich habe heute noch einmal ein paar Minuten mit der Karte verbracht.
Bezüglich Write-Protection: 1 | $ lsblk -o NAME,FSTYPE,PARTLABEL,SIZE,RO
| 2 | NAME FSTYPE PARTLABEL SIZE RO
| 3 | sda 119.2G 0
| 4 | |-sda2 ext4 Linux filesystem 32G 0
| 5 | |-sda3 swap Linux swap 12G 0
| 6 | `-sda4 ext4 Linux filesystem 64G 0
| 7 | mmcblk0 7.4G 0
| 8 | |-mmcblk0p1 vfat 60M 0
| 9 | `-mmcblk0p2 ext4 3.7G 0
|
Der Kernel hat die Karte also ausdrücklich als nicht Read-Only
erkannt.
1. Kennt ihr noch weitere Kommandos zum testen?
2. Lohnt es sich die Karte vorsichtig mal aufzumachen (falls möglich)?
Also nochmals: nicht wegen der Daten sondern wegen der Neugier :-)
Mit freundlichen Grüßen,
N.G.
Das "S" in SD-Karte steht für Security. Es gibt Kommandos, die man nur
per NDA erfährt, wenn man sich in den Kreis der Gruppe "einkauft".
Möglicherweise geht es auch in diese Richtung.
N. G. schrieb:
> Der Kernel hat die Karte also ausdrücklich als nicht Read-Only
> erkannt.
Hat auch niemand behauptet. Sie ignoriert nur Schreibzugriffe, aus
welchem Grund auch immer.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|