Die Raspberry Pi Foundation hat vor einigen Tagen eine komplett reorganisierte Implementierung Ihres Raspberry Pi OS Imager vorgestellt. Das Programm hilft dabei, Raspberry Pi OS oder andere Distributionen auf SD-Karten für den Raspberry Pi zu schreiben. Mit der vorigen Version hatte ich zuletzt Ärger. Aufgrund einer Unachtsamkeit habe ich Raspberry Pi OS über die Windows-Installation auf der zweite SSD meines Mini-PCs geschrieben. Führt Version 2.0 ebenso leicht in die Irre?
Installation unter Linux
Der Raspberry Pi Imager steht für Windows als EXE-Datei und für macOS als DMG-Image zur Verfügung. Installation und Ausführung gelingen problemlos.
Unter Linux ist die Sache nicht so einfach. Die Raspberry Pi Foundation stellt den Imager als AppImage zur Verfügung. AppImages sind ein ziemlich geniales Format zur Weitergabe von Programmen. Selbst Linux Torvalds war begeistert (und das will was sagen!): »This is just very cool.« Leider setzt Ubuntu auf Snap-Pakete und die Red-Hat-Welt auf Flatpaks. Dementsprechend mau ist die Unterstützung für das AppImage-Format.
Ich habe meine Tests unter Fedora 43 durchgeführt. Der Versuch, den heruntergeladenen Imager einfach zu starten, führt sowohl aus dem Webbrowser als auch im Gnome Dateimanager in das Programm Gnome Disks. Fedora erkennt nicht, dass es sich um eine App handelt und bietet stattdessen Hilfe an, in die Image-Datei hineinzusehen. Abhilfe: Sie müssen zuerst das Execute-Bit setzen:
chmod +x Downloads/imager_2.2.0.amd64.AppImage
Aber auch der nächste Startversuch scheitert. Das Programm verlangt sudo-Rechte.
Mit sudo funktioniert es schließlich:
sudo Downloads/imager_2.2.0.amd64.AppImage
Tipp: Beim Start mit
sudomüssen Sieimager_n.n.AppImageunbedingt einen Pfad voranstellen! Wenn Sie zuerst mitcd Downloadsin das Downloads-Verzeichnis wechseln und dannsudo imager_n.n.AppImageausführen, lautet die Fehlermeldung Befehl nicht gefunden. Hingegen funktioniertsudo ./imager_n.n.AppImage.
Bedienung
Ist der Start einmal geglückt, lässt sich das Programm einfach bedienen: Sie wählen zuerst Ihr Raspberry-Pi-Modell aus, dann die gewünschte, dazu passende Distribution und schließlich das Device der SD-Karte aus. Vorsicht!! Wie schon bei der alten Version des Programms sind die Icons irreführend. In meinem Fall (PC mit zwei zwei SSDs und einer SD-Karte) wird das SD-Karten-Icon für die zweite SSD verwendet, das USB-Icon dagegen für die SD-Karte. Passen Sie auf, dass Sie nicht das falsche Laufwerk auswählen!! Ich habe ein entsprechendes GitHub-Issue verfasst.
In den weiteren Schritten können Sie eine Vorabkonfiguration von Raspberry Pi OS vornehmen, was vor allem dann hilfreich ist, wenn Sie den Raspberry Pi ohne Tastatur und Monitor (»headless«) in Betrieb nehmen und sich direkt per SSH einloggen möchten.
Bei den Zusammenfassungen wäre die Angabe des Device-Namens der SD-Karte eine große Hilfe.
Fazit
Die Oberfläche des Raspberry Pi Imager wurde überarbeitet und ist ein wenig übersichtlicher geworden. An der Funktionalität hat sich nichts geändert. Leider kann es weiterhin recht leicht passieren, das falsche Device auszuwählen. Bedienen Sie das Programm also mit Vorsicht!
AppImages sind tatsächlich cool. Da hat der Linus Torvalds schon recht. Wenn es um das Installieren eines Systems geht sind sie allerdings übertrieben kompliziert und verleiten zu Flüchtigkeitsfehlern, siehe oben. Am coolsten sind die Bordwerkzeuge, die den Blick auf das Wesentliche lenken:
erlangen:~ # lsscsi
[1:0:0:0] disk ATA KINGSTON SV300S3 BBF0 /dev/sda
[4:0:0:0] disk ATA CT2000BX500SSD1 030 /dev/sdb
[5:0:0:0] cd/dvd PIONEER DVD-RW DVR-221 1.00 /dev/sr0
[6:0:0:0] disk CT4000P3 SSD8 3108 /dev/sdc
[7:0:0:0] disk ST8000VN 004-2M2101 0 /dev/sdd
[8:0:0:0] disk Generic STORAGE DEVICE 0828 /dev/sde
[9:0:0:0] disk Intenso Ultra Line 1100 /dev/sdf
[10:0:0:0] disk Intenso Ultra Line 1100 /dev/sdg
[N:0:4:1] disk Samsung SSD 970 EVO Plus 2TB__1 /dev/nvme0n1
[N:1:1:1] disk Samsung SSD 990 EVO 2TB__1 /dev/nvme1n1
erlangen:~ #
Der Intenso mit Fedora kann überschrieben werden:
erlangen:~ # lsb /dev/sdf
PATH LABEL UUID FSTYPE MOUNTPOINT
/dev/sdf Fedora-WS-Live-43 2025-10-23-04-15-58-00 iso9660
/dev/sdf1 Fedora-WS-Live-43 2025-10-23-04-15-58-00 iso9660 /media/Fedora-WS-Live-43
/dev/sdf2 BOOT AD6C-5955 vfat
erlangen:~ #
dd kopiert rasch und zuverlässig. Der Schreibcache würde hier nur stören und ist mit „oflag=direct“ abgeschaltet.
erlangen:~ # dd if=agama-installer.x86_64-openSUSE.iso of=/dev/sdf bs=4M status=progress oflag=direct
759169024 bytes (759 MB, 724 MiB) copied, 31 s, 24.5 MB/s768348160 bytes (768 MB, 733 MiB) copied, 31.0918 s, 24.7 MB/s
183+1 records in
183+1 records out
768348160 bytes (768 MB, 733 MiB) copied, 31.1003 s, 24.7 MB/s
erlangen:~ #
Bei
ddmüssen Sie natürlich auch sehr gut aufpassen, dass Sie keinen falschen Device-Namen als Ziel-Device verwenden.Das Kommando „dd“ aus der bash-history hervorzuholen und auszuführen hat sicher irgendwann unerwünschte Auswirkungen. Darum führe ich immer erst „lsscsi“ aus:
erlangen:~ # lsscsi -s
[4:0:0:0] disk ATA CT2000BX500SSD1 030 /dev/sdb 2.00TB
[5:0:0:0] cd/dvd PIONEER DVD-RW DVR-221 1.00 /dev/sr0 1.07GB
[N:0:1:1] disk Samsung SSD 990 EVO 2TB__1 /dev/nvme0n1 2.00TB
[N:1:4:1] disk Samsung SSD 970 EVO Plus 2TB__1 /dev/nvme1n1 2.00TB
erlangen:~ #
Hersteller, Modell und Revision sind meist eindeutig. Das Kommando wird selten erwähnt. Immerhin findet man es im Index der aktuellen Auflage von „Linux, Das umfassende Handbuch“.
https://sg.danny.cz/scsi/lsscsi.html