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.

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 
[...]

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.

Achtung: 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.

$ 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.

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.

Zum Schreiben eines ISO-Images einer Linux-Distribution auf einen USB-Stick wird gerne die eierlegenden Wollmilchsau UNetbootin empfohlen. Es „brennt“ nicht nur auf der Platte liegende ISOs auf den USB-Stick, es lädt auf Wunsch auch eine ganze Reihe von Distributionen aus dem Netz und schiebt sie auf den USB-Stick. So spart man sich auch noch das manuelle Herunterladen der ISO-Datei.

ISO-Image mit dd auf USB-Stick schreiben

UNetbootin ist generell nicht schlecht — gerade wenn man aktuell nur ein Windows installiert hat — aber wozu unter Linux ein umfangreiches Programm installieren, wenn man mit dd doch schon das nötige Werkzeug auf der Platte liegen hat. Die größte Hürde ist dabei herauszufinden, unter welche Geräte-ID der USB-Stick anzusprechen ist: Dabei hilft einem aber das Kommando lsblk.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 59,6G 0 disk
├─sda1 8:1 0 53,7G 0 part /
└─sda2 8:2 0 5,9G 0 part [SWAP]
sdb 8:16 0 596,2G 0 disk
└─sdb1 8:17 0 596,2G 0 part /home
sdg 8:96 1 2G 0 disk
├─sdg1 8:97 1 794M 0 part /run/media/user/usb-stick
└─sdg2 8:98 1 31M 0 part
sr0 11:0 1 1024M 0 rom

Blkid listetet die am Rechner hängenden Blockgeräte — also Festplatten, CD/DVD-ROMs und eben USB-Sticks — als Baum mitsamt der Größe des Speichers auf. So habt ihr schnell das richtige Gerät herausgesucht, ohne dass ihr euch durch die Logs von dmesg oder /var/log/messages graben müsstet — Der Mount-Punkt hängt natürlich von dem Namen ab, den ihr der Partition des Sticks verpasst habt.

$ sudo dd if=/pfad/zu/beispiel.iso of=/dev/sdg; sync

Das Schreiben des ISO-Images übernimmt dann ein Aufruf von dd. Wichtig ist hier vor allen Dingen, dass man den USB-Stick als Ziel angibt. Tut man dies aufgrund einer Verwechselung nicht, dann drohen Datenverluste! Diverse Seiten empfehlen beim Schreiben des ISOs eine bestimmte Block-Größe wie bs=1024K oder bs=10M, bei der heutigen Geschwindigkeit moderner Datenträger und der relativ geringen Größe von typischen ISO-Images mit Linux-Live-ISOs ist der Zusatz in meinen Augen nicht nötig.

ISO-Image mit Gnome-Disk-Tool schreiben

Dass man aber auch mit dem Gnome-Disks-Tool (kurz Disks oder in der Aktivitäten-Übersicht auch Laufwerke genannt) ebenfalls ISO-Images auf USB-Sticks schreiben kann, habe ich erst vor Kurzem bemerkt. Neben ein paar Komfort-Features wie einer Fortschrittsanzeige und Hinweisen, dass der USB-Stick zu groß oder zu klein sein könnte, macht das Gnome-Disks Tools das Heraussuchen des Speicherorts natürlich noch leichter. Der angeschlossene USB-Stick ist in Disks nicht zu übersehen, so sollte das Risiko etwas zu verbasteln eigentlich minimiert werden.

Auch wenn meine Distro-Hopper-Zeiten vorbei sind — wenn ich es recht bedenke hatte ich eigentlich nie so eine Phase — aber dennoch muss ich recht häufig diverse ISO-Images auf einen USB-Stick oder eine Micro-SD-Speicherkarte bannen. Meine kleine Armee aus Raspberry Pis, Odroids oder Banana Pis — dazu hoffentlich in den nächsten Tagen ein wenig mehr — möchte mit Betriebssystemen versorgt werden.

Heute Vormittag bin ich auf diesen Bericht des Nachrichten-Portals ka-news.de aufmerksam geworden. Darin wird in einem Abschnitt die Software Haystack und deren Spendenaufruf erwähnt…

Wer alte USB-Sticks, die er nicht mehr brauchte, im Univers-Imbiß in der Kaiserstraße oder am Infostand abgab, konnte sich sicher sein, damit den Menschen im Iran zu helfen. Denn dank einer darauf gespielten Software namens „Haystack“ – zu deutsch: Heuhaufen – kann damit die Internet-zensur des Regimes umgangen werden und Informationen per Twitter oder youtube verbreitet werden.

Bislang habe ich von Haystack nichts gehört. Lauf der FAQ des Projektes verschlüsselt und versteckt Haystack Traffic zu Kommunikationskanälen wie Twitter oder YouTube in „normalem“ unverfänglichem Traffic. Die USB-Sticks werden gebraucht um Haystack im Iran unter die Leute zu bringen. Weitere technische Details, warum der Source von Haystack nicht (oder besser warum noch nicht) offen gelegt wird, was Haystack von Tor unterscheidet und vieles mehr kann man in der FAQ nachlesen.

Ein bisschen kritisch sehe ich das Projekt. Ohne die Sourcen kann man nur mit aufwändigen Analysen nachprüfen ob Haystack nicht als Doppelagent fungiert. Wer garantiert, dass Haystack nicht alle Daten nach Hause telefoniert? Dagegen spricht das offene Auftreten des Projektes. Der Macher Austin Heap stellt in seinem Blog die Details ausführlich vor und die Seiten machen einen transparenten und organisierten Eindruck.

Ich habe daher meine überzähligen USB-Sticks mittels dd if=/dev/zero of=/dev/sdXY genullt (Bitte das /dev/sdXY noch anpassen) und gehe morgen Mittag mal auf den Karlsruher Marktplatz. Mal schauen ob die noch USB-Sticks im Univers annehmen. Wer Haystack finanziell unterstützen möchte, der findet auf der Projektseite eine Möglichkeit zu spenden.

Was recht eigenartig ist, dass das Programm ein paar Minuten lang behauptet, dass es in wenigen Sekunden fertig sei und dass man auf keinen Fall den Vorgang unterbrechen sollte.

Nun gut, ich hab brav gewartet und nach ein paar Minuten war der Stick dann auch formatiert. Nicht schön ist, dass der Windows Explorer dieses Vorgang nicht so toll findet und sich nach dem formatieren des Sticks aufhängt, aber was soll ich auf einem Linux-Blog über Windows lästern Richtig nett ist auch, dass Windows mich den Stick nicht mit NTFS formatieren lässt… Aber wozu hat man gparted.

Vor kurzem bin ich jedoch über eine brauchbare Alternative gestolpert mit der ich jetzt recht happy bin (Zum Glück sind meine Finger alle noch heile, von daher scheidet für mich die „InFinger“-Variante aus ). Der LaCie iamaKey IST ein Schlüssel. Ein USB-Key so groß und im selben Format wie mein Haustürschlüssel. Dazu noch aus Metall und angeblich wasserunempfindlich.

Für mich die ideale Lösung, ein vom USB-Stick bootbares Linux ist nun immer in meiner Hosentasche und ich glaub auch nicht, dass ich den USB-Key am Rechner vergesse (wie schon zwei, dreimal passiert), denn ohne Schlüssel gehe ich eigentlich nie los. Allerdings habe ich mir nur die 4GB-Version geleistet. Der Aufpreis auf 8GB ist doch recht heftig und so viel Platz brauche ich eigentlich nicht. Unnütz zu erwähnen, dass USB-Sticks eigentlich immer unabhängig vom Betriebsystem funktionieren.