Zum Flashen von ISO-Images auf USB-Sticks nutze ich in der Regel das Kommando dd. Die Syntax dd if=foo.iso of=/dev/sdx bs=1M; sync ist mir nach langen Jahren des Rumspielens mit Linux-Distributionen für PC, Raspberry Pi und Co. schon in Fleisch und Blut übergegangen. Irgendwie habe ich aber immer ein etwas mulmiges Gefühl: Eines Tages werde ich beim Eintippen der Geräte-ID sicher einen Fehler machen. Eines Tages werde ich mal aus Versehen wichtige Daten praktisch unwiederbringlich überschreiben. Ich denke, mit diesem Gefühl werde ich nicht alleine sein.
Von daher finde ich Tools wie die in Gnome eingebaute Funktion zum Flashen von ISOs oder Tools wie Etcher von der Idee sehr gut. Über die grafische Oberfläche hat man als Nutzer doch ein wenig mehr Übersicht und Kontrolle. Die Laufwerksverwaltung von Gnome versteckt die Funktion zum Flashen von ISOs allerdings recht gut und bei Etcher stoße ich mich an Electron. Auch wenn es für Entwickler praktisch sein mag: Nur dafür einen zig MByte großen und per se nutzlosen Software-Blob auf das System zu spülen, finde ich doch ein wenig übertrieben.
Für Nutzer von KDE Plasma gibt es als Alternative den ISO Image Writer. Das Programm fügt sich sauber in die Desktopumgebung ein und trägt nicht sonderlich dick auf. Für Gnome gab es ein solch kleines Programm bisher nicht. Bisher. Seit ein paar Tagen gibt es mit Impression (Github, Flatpak) eine moderne Option auf Basis von GTK4 zum Schreiben von ISO-Images für Anhänger von GTK-Desktops. Die Bedienung ist einfach: Programm starte, ISO-Image und Ziel auswählen, Image schreiben, Fertig. Fehler können hier nicht passieren, da Impression nur USB-Sticks und Speicherkarten, aber keine Festplatten als Zielort anbietet.
Aktuell findet ihr Impression noch nicht in den Paketquellen der üblichen Linux-Distributionen. Via Flatpak klappt die Installation allerdings problemlos. Der Versionszähler der Anwendung steht gerade bei 1.0.0 und der Quellcode ist erst seit ein paar Tagen online, auch die Übersetzung ins Deutsche fehlt noch. Das wird sich aber sicherlich schnell ändern. Und es dauert sicherlich nicht lange, bis Gnome das Projekt in seinen stetig wachsenden Gnome Circle aufnimmt und ihm so deutlich mehr Bekanntheit liefert.
Ü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.
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.
