Über die Jahre haben sich bei mir hier unzählige USB-Sticks und SD-Speicherkarten angesammelt. Oft stammen diese nicht von Markenherstellern, sondern aus der Ramschkiste von Werbematerialprovidern — Pressekonferenzen und Produktpräsentationen sei Dank. In der Praxis merke ich jedoch, dass es durchaus einen Unterschied macht, ob ein Speicherstick von Sandisk, Samsung und einem anderen renommierten Hersteller stammt oder ob das Werbematerial aus irgendeiner asiatischen Hinterhofbude zusammengeschustert wurde. Und dabei rede ich nicht einmal von Fälschungen, die mehr Kapazität vortäuschen, sondern einfach nur von schlechter Qualität und Schreib-/Lesefehlern.

Ich hatte in der letzten Zeit häufig das Problem, dass sich diese miesen Sticks immer oben im Stapel ansammelten und somit beim Griff in die Grabbelkiste immer als erste in meiner Hand lagen. Spätestens beim Schreiben größerer Datenmengen, etwa eines ISO-Images einer Linux-Distribution, kommt es dann zu Problemen. Die Schreib-/Leserate bricht ein oder es gibt gleich aussagekräftigere IO-Fehler. Um diese Problematik auszuschließen, möchte ich also alle meine USB-Sticks und SD-Speicherkarten einmal auf Fehler überprüfen und defekte Datenträger für immer aussortieren. Unter Linux geht das mit Bordmitteln.

USB-Sticks auf Fehler prüfen

Im ersten Schritt müsst ihr die Geräte-ID des USB-Sticks oder der Speicherkarte herausfinden. Steckt den Datenträger daher an den Rechner an oder legt die SD-Karte in das entsprechende Lesegerät und gebt im Terminal lsblk ein. Das Kommando listet euch sämtliche am Rechner angeschlossene Datenträger auf. Anhand der Größe des Datenträgers lässt sich in der Regel die Geräte-ID erkennen. In meinem Beispiel bindet das System meinen 8 GByte großen USB-Stick unter sdc (also /dev/sdc in der vollständigen Syntax) ein. Seid ihr euch nicht sicher, dann zieht den zu kontrollierenden Datenträger ab und wiederholt lsblk. Fehlt sdc in der ausgegebenen Liste, dann habt ihr die richtige Kennung. Alternativ lässt sich die Kennung auch mit grafischen Tools wie der Laufwerksverwaltung von Gnome ermitteln.

$ lsblk
[...]
sdc           8:32   1   7,5G  0 disk 
├─sdc1        8:33   1   2,9G  0 part /run/media/toff/Ubuntu 21.10 amd64
├─sdc2        8:34   1   4,1M  0 part 
└─sdc3        8:35   1   300K  0 part 
[...]
Auch die in Gnome integrierte Laufwerksverwaltung zeigt die Geräte-IDs von Festplatten, SSDs, USB-Sticks und anderen in das System eingebundenen Datenträgern an.

Für die eigentliche Fehlersuche kommt nun das Kommando badblocks aus dem Paket e2fsprogs zum Einsatz, das zur Grundausstattung der üblichen Distributionen gehört. Es kann vorkommen, dass sich Badblocks erst einmal weigert, die Überprüfung zu starten, da das Laufwerk bereits vom System benutzt sei. In der Regel kommt das davon, dass das Betriebssystem den Datenträger automatisch einbindet, sobald ihr den USB-Stick ansteckt. Auf meinem System genügt das Antippen des Icons zum Aushängen des Laufwerks im Dateimanager nicht, ich muss die Geräte-ID des Laufwerks und der dazugehörigen Partitionen gezielt mit umount aushängen.

$ sudo badblocks -wsv /dev/sdc
/dev/sdc wird offensichtlich vom System genutzt; es ist zu unsicher, Badblocks zu starten!
$ sudo umount /dev/sdc*
umount: /dev/sdc: nicht eingehängt.
umount: /dev/sdc2: nicht eingehängt.
umount: /dev/sdc3: nicht eingehängt.

An dieser Stelle muss ich eine Warnung schreiben: Beim Prüfen auf Fehler überschreibt Badblocks sämtliche Daten und Partitionen auf dem angegebenen Datenträger. Stellt daher auf jeden Fall sicher, dass ihr die richtige Geräte-ID an das Kommando übergibt und sichert vor der Aktion wichtige Daten vom betroffenen USB-Stick oder der SD-Speicherkarte. Im Fall der Fälle könnt die Daten nach der Fehlerüberprüfung nicht wiederherstellen.

Beim Aufruf von Badblocks übergebt ihr dem Kommando die Parameter -wsv sowie die Geräte-ID. Die Parameter weisen das Programm an, einen destruktiven Schreibtest auszuführen (-w), den Fortschritt anzuzeigen (-s) und generell mehr Informationen auszugeben (-v). Der ausführliche Test beschreibt jeden Block des Datenträgers viermal hintereinander mit unterschiedlichen Mustern (0xaa, 0x55, 0xff und 0x00). Je nach Geschwindigkeit und Kapazität müsst ihr dafür eine längere Zeit einplanen. Die Prüfung des von mir im Beispiel benutzten USB-Sticks nach dem USB-2.0-Standard und 8 GByte Kapazität benötigte über eine Stunde.

$ sudo badblocks -wsv /dev/sdc
Es wird getestet Mit Muster 0xaa:   0.00% erledigt, 0:00 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x55:   0.00% erledigt, 23:47 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0xff:   0.00% erledigt, 47:33 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x00:   0.00% erledigt, 1:11:26 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt

Neben der destruktiven Prüfmethode unterstützt Badblocks einen zerstörungsfreien Lesen+Schreiben-Modus. Diesen aktiviert ihr mit dem Parameter -n anstatt von -w. In dieser Variante sichert Badblocks die Daten des geprüften Speicherblocks zuerst in den Arbeitsspeicher, überschreibt dann den Datenblock mit Zufallsdaten und prüft, ob die Daten korrekt geschrieben werden konnten. Abschließend schreibt Badblocks die Sicherung wieder auf den Datenträger zurück. Auf den ersten Blick erscheint die Prüfroutine schneller, da es nur einen Prüfdurchlauf gibt, in der Praxis brauch das Sichern und Zurückschreiben der bestehenden Daten allerdings wesentlich mehr Zeit. In meinem Beispiel anstatt nur etwas mehr als einer Stunde über 2,5 Stunden.

$ sudo badblocks -nsv /dev/sdc
Es wird nach defekten Blöcken im zerstörungsfreien Lesen+Schreiben-Modus gesucht
Von Block 0 bis 7812607
Es wird nach defekten Blöcken gesucht (zerstörungsfreier Lesen+Schreiben-Modus)
Es wird mit zufälligen Mustern getestet:  94.36% erledigt, 2:35:18 verstrichen. (0/0/0 Fehler)

Gefälschte USB-Sticks ermitteln

Einen Schritt weiter geht das Tool F3 oder etwas länger Fight Flash Fraud. Das Open-Source-Programm prüft ausführlich, ob ein Datenträger wirklich die Kapazität besitzt, die er vorgibt zu haben. Ein Thema, das leider immer noch aktuell ist, besonders wenn man super günstige Angebote aus dem Internet kauft. Um gefälschte USB-Sticks oder SD-Speicherkarten aufzudecken, müsst ihr das Programm aus dem Paketquellen installieren. Debian, Ubuntu, Fedora und Co. führen das Konsolenwerkzeug in den offiziellen Repositories, das Paket nennt sich in der Regel f3. Arch Linux führt das Programm nur im AUR, zur Installation braucht ihr daher einen AUR-Helper.

### Installation unter Arch Linux oder Manjaro:
$ yay -S f3
### Installation unter Debian, Ubuntu oder Raspberry Pi OS:
$ sudo apt install f3

Die Kommandos zum Prüfen von USB-Datenträgern lauten nun f3write, f3read und f3probe. Die ersten zwei Befehle müsst ihr in Kombination nutzen. Als Option übergebt ihr den Kommandos jeweils den Mountpunkt des Datenträgers. f3write schreibt nun so lange ein Gigabyte große Dateien auf den eingebundenen Datenträger, bis der Platz ausgeht. Anschließend prüft ihr mit f3read, ob die geschriebenen Daten auch wirklich wieder gelesen werden können. Falls es sich um einen gefälschten USB-Stick oder eine manipulierte SD-Speicherkarte handeln sollte, dann würde f3read korrupte Sektoren ausgeben. Bei dieser Prüfung bleiben alle Daten auf dem Datenträger erhalten, ihr müsst am Ende nur wieder die h2w-Dateien löschen, sonst habt ihr keinen Platz mehr auf dem Stick.

$ f3write /run/media/toff/291E-6F9C
[...]
Free space: 3.72 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.91 MB/s
$ f3read /run/media/toff/291E-6F9C
[...]
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1518736/        0/      0/      0

  Data OK: 3.72 GB (7810192 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 14.73 MB/s
$ ls -al /run/media/toff/291E-6F9C
insgesamt 3907596
drwxr-xr-x  3 toff toff       4096  1. Jan 1970   .
drwxr-x---+ 4 root root         80  7. Dez 16:27  ..
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:35  1.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:40  2.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:44  3.h2w
-rw-r--r--  1 toff toff  777592832  7. Dez 18:47  4.h2w
[...]

Ein wenig schneller arbeitet f3probe --destructive. Die Option --destructive ist optional, die beschleunigt die Aktion jedoch ganz wesentlich. Bei diesem Test beschreibt F3 nur die nötigsten Sektoren und kümmert sich auch nicht um eine Datensicherung. Da die Probe direkt auf die Hardware zugreif, gebt ihr als Parameter nicht den Mountpunkt sondern die Geräte-ID (hier /dev/sdg) an. Der Test mit meinem 4 GByte großen USB-2.0-Stick dauert so nur ein wenig mehr als sieben Minuten. Habt aber bei dieser Prüfung wieder im Hinterkopf, dass die Routine sämtliche Datenblöcke auf dem Datenträger überschreibt.

$ f3probe --destructive --time-ops /dev/sdg
[...]
Good news: The device `/dev/sdg' is the real thing

Device geometry:
	         *Usable* size: 3.73 GB (7831552 blocks)
	        Announced size: 3.73 GB (7831552 blocks)
	                Module: 4.00 GB (2^32 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 7'17"
 Operation: total time / count = avg time
      Read: 2.73s / 4812 = 568us
     Write: 7'13" / 3637313 = 119us
     Reset: 1us / 1 = 1us

Sowohl Badblocks als auch F3 helfen beim Analysieren von Fehlern auf Datenträgern. Bei der Prüfung müsst ihr allerdings immer ein wenig Zeit mitbringen. Die ausführliche Analyse eines 8 GByte großen USB-Sticks kann schonmal zwei Stunden dauern, besonders wenn bei der Prüfung die Daten erhalten bleiben sollen und der USB-Stick nur mit dem langsamen USB-2.0-Protokoll arbeitet. Danach könnt ihr aber davon ausgehen, dass der USB-Stick oder die SD-Speicherkarte auch wirklich funktionieren und die Kapazität besitzen, die auf dem Aufdruck steht.

7 Kommentare

  1. Hallo Christoph,
    genau nach einem solchen Tool hab ich gesucht.
    Und bin auch gleich in meiner Krabbelkiste fündig geworden.

    F3 probe 8.0
    Copyright (C) 2010 Digirati Internet LTDA.
    This is free software; see the source for copying conditions.
    
    WARNING: Probing normally takes from a few seconds to 15 minutes, but
             it can take longer. Please be patient.
    
    Bad news: The device `/dev/sdc' is a counterfeit of type limbo
    
    You can "fix" this device using the following command:
    f3fix --last-sec=61239551 /dev/sdc
    
    Device geometry:
                     *Usable* size: 29.20 GB (61239552 blocks)
                    Announced size: 1.91 TB (4096000000 blocks)
                            Module: 2.00 TB (2^41 Bytes)
            Approximate cache size: 3.00 MB (6144 blocks), need-reset=no
               Physical block size: 512.00 Byte (2^9 Bytes)
    
    Probe time: 25.80s
     Operation: total time / count = avg time
          Read: 691.6ms / 16572 = 41us
         Write: 25.07s / 87020 = 288us
         Reset: 1us / 2 = 0us

    Vielen dank!

    — Gyges

  2. Ich habe einen USB-Stick von PQI mit 32GB. Der hat seinen Namen geändert und heisst neu „Silicon Motion,Inc. USB MEMORY BAR (1000)“. Er wird nur noch als Laufwerk ohne Kapazität erkannt.
    lsblk zeigt den mit sdb 8:16 1 0B 0 disk an.
    Was ist das? Was dann?
    Eventuell ist die Firmware auf dem USB-Stick zerschossen.
    Wie kann man die unter Linux mit seriösen Mitteln wieder herstellen(flashen)?

    • Hallo Andreas, ich wüsste nicht, dass man bei USB-Sticks eine Firmware flashen könnte. Für mich sieht es so aus, als ob das System denkt einen Kartenleser ohne eingelegten Datenträger vor sich zu haben. Bei mir sieht das beispielsweise so aus:

      $ lsblk
      [...]
      sde           8:64   1     0B  0 disk 
      sdf           8:80   1     0B  0 disk 
      sdg           8:96   1     0B  0 disk 

      Bist du sicher, dass sdb die aktuell richtige Geräte-ID ist?

      • Doch, die haben eine Firmware. Die liegt vielleicht auch auf den ersten Sektoren/Spuren des Sticks. Oder in einem Controller-Chip. Und kann zerschossen werden. Die lässt sich auch restaurieren. Googlen nach „usb stick firmware repair“. Viele USB-Sticks liessen sich wahrscheinlich auch wiederverwenden, wenn die FW wieder hergestellt wurde. Siehe hier oder hier.

        Der defekte Stick ist bei mir LW /dev/sdb. Die LED am Stick blinkt/leuchtet. Er lässt sich nicht mehr verwenden. Lässt sich nicht auswerfen, weil kein Medium. Aber ausschalten. Dann geht die LED aus. Unter lsusb meldet er sich mit ID 090c:3000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) SM3255AA MEMORY BAR. Gleiches Drama hier in einem Thread bei den Linuxmintusers.

        Die Tools im Internet sind meist aus Russland/China und veraltet, etwa das hier. Gibt es eine Möglichkeit unter Linux, diese USB-Sticks wieder neu mit der FW zu beschreiben? Das wäre doch eigentlich etwas für fwupd

        Gruss
        AW

Kommentieren Sie den Artikel

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein