• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Erledigt] SD-Card verweigert Schreibzugriffe ohne Fehlermeldung

gehrke

Administrator
Teammitglied
Moin *,

ich habe hier eine störrische SD-Card: SanDisk Ultra microSD HC 32GB
Sie verweigert ohne Fehlermeldung Schreibzugriffe, lesende Zugriffe sind aber erfolgreich.

Code:
# journalctl -f
Apr 13 22:30:30 j2.gehrke.local kernel: usb 2-3: new high-speed USB device number 17 using ehci-pci
Apr 13 22:30:30 j2.gehrke.local kernel: usb 2-3: New USB device found, idVendor=048d, idProduct=1345
Apr 13 22:30:30 j2.gehrke.local kernel: usb 2-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 13 22:30:30 j2.gehrke.local kernel: usb 2-3: Product: Mass Storage Device
Apr 13 22:30:30 j2.gehrke.local kernel: usb 2-3: Manufacturer: Generic
Apr 13 22:30:30 j2.gehrke.local kernel: usb 2-3: SerialNumber: 000000000000100
Apr 13 22:30:30 j2.gehrke.local kernel: usb-storage 2-3:1.0: USB Mass Storage device detected
Apr 13 22:30:30 j2.gehrke.local kernel: scsi host15: usb-storage 2-3:1.0
Apr 13 22:30:30 j2.gehrke.local mtp-probe[553]: checking bus 2, device 17: "/sys/devices/pci0000:00/0000:00:1d.7/usb2/2-3"
Apr 13 22:30:30 j2.gehrke.local mtp-probe[553]: bus: 2, device: 17 was not an MTP device
Apr 13 22:30:31 j2.gehrke.local kernel: scsi 15:0:0:0: Direct-Access     Generic  Compact Flash    0.00 PQ: 0 ANSI: 2
Apr 13 22:30:32 j2.gehrke.local kernel: scsi 15:0:0:1: Direct-Access     Generic  SM/xD-Picture    0.00 PQ: 0 ANSI: 2
Apr 13 22:30:32 j2.gehrke.local kernel: scsi 15:0:0:2: Direct-Access     Generic  SDXC/MMC         0.00 PQ: 0 ANSI: 2
Apr 13 22:30:32 j2.gehrke.local kernel: scsi 15:0:0:3: Direct-Access     Generic  MS/MS-Pro/HG     0.00 PQ: 0 ANSI: 2
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:0: Attached scsi generic sg3 type 0
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:1: Attached scsi generic sg4 type 0
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: Attached scsi generic sg5 type 0
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:0: [sdc] Attached SCSI removable disk
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:3: Attached scsi generic sg6 type 0
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:1: [sdd] Attached SCSI removable disk
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: [sde] 60367872 512-byte logical blocks: (30.9 GB/28.7 GiB)
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: [sde] Write Protect is off
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: [sde] Mode Sense: 03 00 00 00
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:3: [sdf] Attached SCSI removable disk
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: [sde] No Caching mode page found
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: [sde] Assuming drive cache: write through
Apr 13 22:30:32 j2.gehrke.local kernel:  sde: sde1
Apr 13 22:30:32 j2.gehrke.local kernel: sd 15:0:0:2: [sde] Attached SCSI removable disk
Apr 13 22:30:33 j2.gehrke.local kernel: FAT-fs (sde1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Apr 13 22:30:33 j2.gehrke.local udisksd[3114]: Mounted /dev/sde1 at /run/media/gehrke/3464-3337 on behalf of uid 1000

Ich habe mehrere Computer mit unterschiedlichen Readern und unterschiedlichen Adaptern versucht, CentOS und Fedora.

Schreibzugriffe durch KDE, Gnome, fdisk, mkfs, dd. Keines davon meldet Fehler, aber der Zustand danach ist wie davor.
Den Lock an den Adaptern habe ich deaktiviert.

Für mich sieht das so aus, als ob der Controller auf der Karte defekt ist und ich das Ding entsorgen muss. Möglicherweise eine China-Fälschung... Spannend ist ja, dass der gesamte Datenbestand (VFAT) scheinbar noch verfügbar ist.
Oder kann ich noch irgendetwas sinnvoll versuchen?
TNX


cu, gehrke
 

spezi

Advanced Hacker
Guten Morgen,
ich gehe mal davon aus das die Karte vorher in einem Smartphone oder Tablet gesteckt hat und dort formatiert wurde. Dann ist Deine Karte ist nicht im Eimer, sondern exFat formatiert. Die Karte wird erkannt, aber diese Formatierung kann nicht eingebunden werden.

Wenn nicht, dann fsck

mfg
spezi
 
OP
gehrke

gehrke

Administrator
Teammitglied
TNX. 'Korruptes Dateisystem' habe ich gesehen, aber reparierender Dateisystemcheck ist auch schreibender Zugriff. Kann ich machen, tut aber nix:

Code:
[root@j2 ~]# df -h /run/media/gehrke/3464-3337
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf                                                                                                     
/dev/sde1        29G     22G  6,9G   77% /run/media/gehrke/3464-3337                                                                                          

[root@j2 ~]# umount /dev/sde1
Code:
[root@j2 ~]# fsck.vfat -aw /dev/sde1
fsck.fat 3.0.20 (12 Jun 2013)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Performing changes.
/dev/sde1: 8178 files, 718189/942864 clusters
Code:
[root@j2 ~]# fsck.vfat -aw /dev/sde1
fsck.fat 3.0.20 (12 Jun 2013)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
 Automatically removing dirty bit.
Performing changes.
/dev/sde1: 8178 files, 718189/942864 clusters
Code:
[root@j2 ~]# mkfs.ext4 /dev/sde1
mke2fs 1.42.9 (28-Dec-2013)
Dateisystem-Label=
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=0 Blöcke, Stripebreite=0 Blöcke
1888656 Inodes, 7544960 Blöcke
377248 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=2155872256
231 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
8176 Inodes pro Gruppe
Superblock-Sicherungskopien gespeichert in den Blöcken: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000

Platz für Gruppentabellen wird angefordert: erledigt                        
Inode-Tabellen werden geschrieben: erledigt                        
Erstelle Journal (32768 Blöcke): erledigt
Schreibe Superblöcke und Dateisystem-Accountinginformationen: erledigt
Code:
[root@j2 ~]# fdisk /dev/sde
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Befehl (m für Hilfe): p

Disk /dev/sde: 30.9 GB, 30908350464 bytes, 60367872 sectors
Units = Sektoren of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sde1            8192    60367871    30179840    c  W95 FAT32 (LBA)

Befehl (m für Hilfe): d
Selected partition 1
Partition 1 is deleted

Befehl (m für Hilfe): n
Partition type:
   p   primary (0 primary, 0 extended, 4 free)
   e   Erweiterte
Select (default p): p
Partitionsnummer (1-4, default 1):  
Erster Sektor (2048-60367871, Vorgabe: 2048): 
Benutze den Standardwert 2048
Last Sektor, +Sektoren or +size{K,M,G} (2048-60367871, Vorgabe: 60367871): 
Benutze den Standardwert 60367871
Partition 1 of type Linux and of size 28,8 GiB is set

Befehl (m für Hilfe): p

Disk /dev/sde: 30.9 GB, 30908350464 bytes, 60367872 sectors
Units = Sektoren of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sde1            2048    60367871    30182912   83  Linux

Befehl (m für Hilfe): w
Die Partitionstabelle wurde verändert!

Rufe ioctl() um Partitionstabelle neu einzulesen.
Synchronisiere Platten.
Code:
[root@j2 ~]# fdisk -l /dev/sde

Disk /dev/sde: 30.9 GB, 30908350464 bytes, 60367872 sectors
Units = Sektoren of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sde1            8192    60367871    30179840    c  W95 FAT32 (LBA)
Code:
[root@j2 ~]# time dd if=/dev/zero of=/dev/sde bs=1M
dd: Fehler beim Schreiben von „/dev/sde“: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
29477+0 Datensätze ein
29476+0 Datensätze aus
30908350464 Bytes (31 GB) kopiert, 2093,46 s, 14,8 MB/s

real    34m53.678s
user    0m0.042s
sys     0m29.299s
Code:
[root@j2 ~]# fdisk -l /dev/sde

Disk /dev/sde: 30.9 GB, 30908350464 bytes, 60367872 sectors
Units = Sektoren of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x00000000

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sde1            8192    60367871    30179840    c  W95 FAT32 (LBA)

Code:
[root@j2 ~]# mount -v /dev/sde1 /mnt
mount: /dev/sde1 mounted on /mnt.
<... alle Dateien sind unverändert vorhanden ...>

Entsorgen?
 

josef-wien

Ultimate Guru
gehrke schrieb:
Ich fürchte, Dir bleibt keine andere Wahl. Wie alt ist das Medium bzw. wie oft wurde es schon beschrieben? Solche Reaktionen würde ich erwarten, wenn die Speicherzellenblöcke nicht mehr gelöscht und dadurch zum Neubeschreiben der einzelnen Speicherzellen bereitgestellt werden können, aber selbst den Primitiv-Controllern auf Speicherkarten hätte ich zugetraut, das nicht kommentarlos über die Bühne gehen zu lassen. Wenn es nicht an der abgelaufenen Lebensdauer der Speicherzellen liegt, dann muß wohl der Controller weitgehend seinen Geist aufgegeben haben.

P. S. Diese beim Einhängen auftretende Fehlermeldung (die bereits kommt, wenn man ein "FAT-Medium" zuvor ohne "sicher entfernen" abgezogen und damit das Entfernen des "dirty bit" verhindert hat) hindert das System üblicherweise nicht daran, das Medium trotzdem schreibbar einzuhängen.
 

spezi

Advanced Hacker
Hallo,
ich hatte das mit einer 128 Gb SD Karte. Wenn Du noch ein Windows hast (ich bin zum Nachbar gegangen), probier das mal damit. Da ging dann r/w.
Ich weiss, das ist ein Sch....vorschlag :-(. Aber mir ist nichts besseres eingefallen.

mfg
spezi
 
OP
gehrke

gehrke

Administrator
Teammitglied
josef-wien schrieb:
Wie alt ist das Medium bzw. wie oft wurde es schon beschrieben?
Circa 1-2 Jahre, Einsatz in einem Android-Smartphone. Allerdings sagte mir die Besitzerin der Karte, dass Sie schon gleich zu Beginn Probleme damit gehabt hat, was auch immer das genau heißen mag...

Ich vermute fast, dass es sich hier um eine betrügerische Fälschung handelt. Das Vorgaukeln von mehr Speicher als tatsächlich verbaut ist oder so was, liest man ja immer wieder. Zukünftig werde ich solche Karten wohl direkt bei Ankunft mal einer genauen Prüfung unterziehen müssen.

Windows kann ich auch noch mal prüfen, aber bei den bisherigen Ergebnissen würde es mich sehr wundern, wenn da etwas anderes bei raus kommen sollte...
 
OP
gehrke

gehrke

Administrator
Teammitglied
Das Verhalten bei Windows7 sieht ganz genau so aus. Es wird ein Fehler beim Dateisystem diagnostiziert und ein Dateisystem-Check rödelt 20 Minuten auf der Disk rum. Danach sei alles gut.

Ich kann eine Datei löschen und sie scheint auch weg, aber nach dem nächsten Mounten ist der Dateisystem-Fehler wieder da und die gelöschte Datei auch. Lediglich beim vollständigen Formatieren zeigt Windows nach 20 Minuten eine lapidare Fehlermeldung:
Code:
Formatierung kann nicht abgeschlossen werden.
Und nach dem nächsten Mount ist alles wieder da.

Das ist also unabhängig von Betriebssystem und kann IMHO nur am Controller der SD-Card liegen. Es fällt mir schwer, hier eine andere Erklärung zu vermuten als eine absichtliche Manipulation seitens des Herstellers.
Mit anderen Worten: Betrug.

Und wie es aussieht, werden die damit auch durchkommen, denn sicherlich werde ich jetzt nicht für einen vermuteten Restwert von ~5€ irgendetwas unternehmen. Zumal der Kauf schon lange zurückliegt und ich die Karte voller persönlicher Daten für Reklamationszwecke mit offenem Ausgang garantiert nicht aus der Hand geben werde. :zensur:

Ich werde das Ding entsorgen.
TNX
 
Versuche das (nicht gemounted!):

Code:
# tr '\000' '\377' < /dev/zero | dd of=/dev/sde oflag=seek_bytes seek=16 bs=496 count=1
# dd if=/dev/sde bs=512 count=1 of=/tmp/dump.bin
# hexdump -C -v /tmp/dump.bin

Resultat?
 

josef-wien

Ultimate Guru
Eine Endloskette von hexadezimal FF erzeugen und von Stelle 17 bis 512 in die Ausgabedatei /dev/sde schreiben, die dann 512 Bytes lang ist und am Anfang 16mal hexadezimal 00 hat?

Nachdem Dein
Code:
dd if=/dev/zero of=/dev/sde
keinen Erfolg hatte, wird obige Aktion (deren Unsinn sich mir nicht erschließt) ebenfalls ins Leere gehen. Die zweite und dritte Zeile zur Anzeige des MBR erledigt man einfacher ohne Hilfsdatei:
Code:
hexdump -s0 -n512 -C /dev/sde
 
gehrke schrieb:

Wir geben damit dem controller bekannt, dass der Bereich von 0x010 - 0x1FF mit Bytes 0xFF gelöscht werden soll ( 0xFF wird nicht geschrieben sondern das byte gelöscht).
Von Adresse 0 - 0xF lassen wir die bytes stehen wie sie sind. Das dient nur dazu um danach zu sehen, ob der Löschvorgang funktioniert hat.
Gelöscht wird also der erste Sektor der partition mit Größe 512 bytes, außer die ersten 16 bytes.
Danach lesen wir diesen Sektor gesamt in ein file. Die Kommunkation kernel_driver <> usb_host und NFC controller arbeitet asynchron. Ich will damit sicherstellen,
dass der Kontent aus dem Flash stammt und nicht aus dem cache des drivers. Schließlich wird das file mit hexdump ausgegeben und sollte exakt eine Sektorengröße sein
mit dem von uns gewünschten Inhalt.

Gruß
Gräfin Klara

p.s.
Es wäre von Vorteil vorher zu prüfen, ob
# cat /sys/block/sde/queue/physical_block_size
512 ergibt.
 
OP
gehrke

gehrke

Administrator
Teammitglied
Code:
[root@j2 ~]#  cat /sys/block/sde/queue/physical_block_size
512
Code:
[root@j2 ~]# umount /dev/sde1
Code:
[root@j2 ~]# tr '\000' '\377' < /dev/zero | dd of=/dev/sde oflag=seek_bytes seek=16 bs=496 count=1
1+0 Datensätze ein
1+0 Datensätze aus
496 Bytes (496 B) kopiert, 0,0160241 s, 31,0 kB/s
Code:
[root@j2 ~]# dd if=/dev/sde bs=512 count=1 of=/tmp/dump.bin
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes (512 B) kopiert, 0,00179273 s, 286 kB/s
Code:
[root@j2 ~]#  hexdump -C -v /tmp/dump.bin
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 82  |................|
000001c0  03 00 0c fe ff ff 00 20  00 00 00 04 99 03 00 00  |....... ........|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200
 
Wie man sehen kann, ist der usb_phy und der controller ok
aber der flash läßt sich weder beschreiben noch löschen.
Tut mir leid, da ist nichts mehr zu machen.

Gruß
Gräfin Klara
 
OP
gehrke

gehrke

Administrator
Teammitglied
Verfahren zur Überprüfung der Kapazitätsangabe SD-Card: https://linux-club.de/forum/viewtopic.php?f=92&t=121810
 

karei90

Newbie
Bei mir hatte sich leider auch eine Micro SD Karte entgültig verabschiedet. Hat damit keine 2 Jahre durchgehalten und das bei angeblich hochwertiger Markenware..
Leider war auch die Datensicherung nicht mehr zu gebrauchen, also blieb mir nur der Weg die Karte zu einer Spezialfirma zu schicken um doch noch an die Daten heran zu kommen. Glücklicherweise konnte das Team von <Firmenname entfernt> einen Großteil der Daten auf der Karte retten. Jetzt bin ich zwar ein paar Euros los, aber immerhin hat das ganze war das ganze Vorhaben innerhalb einer Woche problemlos abgewickelt.
 
Oben