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

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.

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.

Beim offiziellen Betriebssystem für den Raspberry Pi, dem inzwischen Raspberry Pi OS getauftem Raspbian, haben die Entwickler der Raspberry Pi Foundation das Rad nicht neu erfunden. Anstatt extra eine eigene Distribution aus dem Boden zu stampfen, setzen sie lieber auf Debian als Grundsystem und passen die Software an die eigenen Bedürfnisse und Vorstellungen an. Mit dem Erscheinen einer neuen Debian-Version gibt es somit aber auch immer eine neue Ausgabe des Raspberry Pi OS. So geschehen Anfang November dieses Jahres: Das Raspberry Pi OS „Bullseye“ ersetzt „Buster“, genauso wie beim Vorbild Debian, das den Sprung auf Bullseye bereits im August gemacht hat.

Nutzer bekommen das Upgrade nun nicht automatisch auf den RasPi gespielt. Das Upgrade muss man von Hand einleiten. Dabei spielt das System nicht nur einen neuen Linux Kernel auf die Speicherkarte, sondern alle bis dahin aufgelaufenen Neuerungen aus dem Open-Source-Universum rund um GNU/Linux. Für Nutzer des Raspberry Pi 4 oder des Compute Module 4 mit dem aktuellen Chipsatz (zu erkennen an der auf dem Chipsatz aufgedruckten Endung C0T) bedeutet das sogar ein wenig mehr Geschwindigkeit, da das System damit ganz offiziell mit 1,8 GHz laufen darf. Wie bei Distributions-Upgrade allerdings üblich sollte man vor der Aktion ein Backup starten.

System- und Firmware-Upgrade

In meinem kleinen Heimnetz läuft ein Raspberry Pi 3 als kleine eierlegende Wollmilchsau. Der Mini-Rechner filtert mittels PiHole Anzeigen aus dem Datenstrom. Er tunnelt via WireGuard einen sicheren Zugang via VPN durch das Internet ins eigene LAN. Zudem macht mein Raspberry Pi einen steinalten Canon-Scanner netzwerkfähig. Von daher sind bei diesem System einige Dienste eingerichtet und das System an mehr als einer Stelle individuell konfiguriert. Ich war daher skeptisch, ob das Upgrade ohne Komplikationen durchläuft und habe erst einmal ein paar Wochen abgewartet, bis etwaige Schwierigkeiten im Upgrade-Prozess ausgebügelt werden konnten.

### Bestehende Installation auf aktuellen Stand bringen:
$ sudo apt update
$ sudo apt full-upgrade
$ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
[...]
 *** Backing up modules 5.10.63-v7+
#############################################################
WARNING: This update bumps to rpi-5.10.y linux tree
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=288234
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)

Im oben aufgeführten ersten Schritt solltet ihr die bestehende Installation des Raspberry Pi OS auf einen aktuellen Stand bringen. Ich selbst arbeite auf meinen RasPi ohne grafische Oberfläche, logge mich daher via SSH auf dem System ein. Alternativ könnt ihr das Upgrade natürlich aber auch unter der grafischen Oberfläche des Systems ausführen. Der letzte Schritt sudo rpi-update ist optional: Er bringt die direkt auf dem Raspberry Pi installierte Firmware auf den neusten Stand. Wie immer bei solchen Firmware-Updates ist hier Vorsicht angebracht. Theoretisch könnt ihr damit das System in das Nirvana schicken, auf der anderen Seite bügelt solch ein Update aber auch Schwächen aus oder schaltet neue Funktionen frei.

Upgrade auf Buster auf Bullseye

Zur Sicherheit startet ihr das System nach diesem Upgrade einmal durch und kontrolliert, ob der Raspberry Pi auch sicher mit Strom versorgt wird. Das komplette Upgrade hat bei mir in etwa zwei Stunden gedauert, während dieser Zeit sollte der Strom auf keinen Fall ausfallen. Loggt euch nun wieder in das System ein und erstellt zunächst eine Sicherheitskopie der für die Paketverwaltung zuständigen Konfigurationsdatei /etc/apt/sources.list. Das nächste Kommando im folgenden Listing tauscht dann jede Erwähnung von buster gegen bullseyeinnerhalb der Datei. Alternativ könnt ihr diesen Schritt natürlich auch mit einem Texteditor erledigen.

### Upgrade auf Raspberry Pi OS Bullseye einspielen:
$ sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
$ sudo apt update
[...]
Reading state information... Done
429 packages can be upgraded. Run 'apt list --upgradable' to see them.
$ sudo apt full-upgrade

Danach lasst ihr mit sudo apt update die Paketquellen neu einlesen und startet abschließend mit dem sudo apt full-upgrade den eigentlichen Upgrade-Prozess, der auf meinem System über 300 MByte an neuen Paketen in das System spült. Das Upgrade läuft mehr oder minder automatisch durch, allerdings informiert die Paketverwaltung zwischendurch über eine Reihe von Neuerungen, die ihr mit [Q] quittieren müsst. Sind wie bei mir Dienste installiert, fragt das Upgrade zudem im weiteren Verlauf ab, ob ihr die Dienste während des Upgrade-Prozesses ohne Nachfrage neu starten möchtet — in der Regel könnt ihr das erlauben.

Kritisch wird es bei Nachfragen wie hier im nachfolgenden Bild. In diesem Fall registriert die Paketverwaltung eine Änderung an der Konfigurationsdatei /etc/default/useradd. Ihr habt nun die Wahl: Mit [Y] das unveränderte Original des Entwicklers zu übernehmen und somit eure eigenen Änderungen zurückzusetzen oder mit [N] eure Version der Konfiguration zu behalten und somit eventuell Neuerungen des Dienstes zu verpassen. Am besten schaut ihr euch mit [D] den Unterschied zwischen beiden Versionen an und entscheidet dann von Fall zu Fall, was zu tun ist. Ganz ohne Wissen über die betroffenen Dienste kann es hier allerdings zu ein paar kniffligen Situationen kommen. Ich für meinen Teil übernehme gerne die Version der Paketentwickler und passe meine Konfiguration danach wieder von Hand an.

Auf meinen Raspberry Pi 3 mit einer Reihe von Diensten hat das System in etwa zwei Stunden an dem Upgrade gearbeitet — allerdings war ich zwischendurch immer wieder mal nicht am Platz, das Upgrade hat dadurch immer mal wieder auf meine Eingaben gewartet. Nach der erfolgreichen Installation von Raspberry Pi OS Bullseye meldet das System am Ende den Wunsch nach einem Neustart an. Startet daher den Raspberry mit dem Kommando sudo reboot einmal neu und meldet euch wieder am System an. Als letzten Schritt kontrolliert ihr, ob das System nun wirklich mit Bullseye läuft und entfernt nicht mehr benötigte Pakete aus dem System. Danach ist euer Raspberry Pi auf dem neusten Stand und wieder bereit für seine Aufgaben im Netz.

$ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
[...]
$ sudo apt autoremove
[...]
0 upgraded, 0 newly installed, 40 to remove and 0 not upgraded.
After this operation, 173 MB disk space will be freed.

Kleiner Tipp am Ende: Wie eingangs angesprochen dürfen die aktuell gefertigten Raspberry Pi 4 und Compute Model 4-Platinen (mit der Kennung C0T am Ende der aufgedruckten CPU-Kennzeichnung) nun ganz offiziellem mit einer Taktrate von 1,8 GHz arbeiten. Damit die CPU jedoch überhaupt so hoch taktet, müsst ihr in der Datei /boot/config.txt die Zeile arm_freq=1800 eintragen. Ansonsten habt ihr bis zur nächsten großen Änderung am System wieder ein wenig Zeit. Das nächste große Update steht analog zum Release-Zyklus von Debian in etwa zwei Jahren an, die Basis bildet dann Debian 12 „Bookworm“.