Raspberry Pi Imager 2.0 unter Linux: Installation, Root-Rechte, CLI und Tipps

In der letzten Zeit bringe ich meine Raspberry Pis wieder deutlich häufiger zum Einsatz. Und wer neue Projekte auf dem Minirechner startet, der landet zwangsläufig wieder beim Raspberry Pi Imager. Als ich das Programm zuletzt häufiger genutzt habe, war es noch ein schlichtes Fenster mit drei Knöpfen und einem versteckten Einstellungsdialog.

Von daher wollte ich mal wieder schauen, was sich beim Imager so getan hat. Die kurze Antwort: eine ganze Menge. Die lange Antwort – mit besonderem Blick auf uns Linux-User und die kleinen Stolperfallen, die in den meisten Anleitungen unter den Tisch fallen – gibt es in diesem Artikel.

Was ist der Raspberry Pi Imager?

Der Raspberry Pi Imager ist das offizielle Werkzeug der Raspberry Pi-Macher, um Betriebssystem-Images auf eine microSD-Karte, einen USB-Stick oder eine SSD zu schreiben. Anders als bei einem schnöden dd lädt der Imager die Images direkt herunter, entpackt sie on the fly, schreibt sie und prüft anschließend das Ergebnis.

Neben Raspberry Pi OS findet ihr in der Auswahl auch Ubuntu, Mediacenter-Distributionen, Retro-Gaming-Systeme, Images für 3D-Drucker und Heimautomatisierung sowie Hilfs-Images, etwa zum Aktualisieren des Bootloaders. Das Programm steht unter der Apache-2.0-Lizenz, der Quellcode liegt auf GitHub. Ihr könnt also jederzeit nachschauen, was es auf eurem Rechner treibt.

Der eigentliche Clou ist aber die Vorkonfiguration: Hostname, Benutzerkonto, WLAN, Zeitzone, Tastaturlayout und SSH-Zugang lassen sich schon vor dem ersten Start festlegen. Der Pi kommt dann direkt fertig eingerichtet ins Netz – ideal für den Headless-Betrieb, bei dem ihr ohne Monitor und Tastatur auskommen wollt.

Was ist neu im Raspberry Pi Imager 2.0?

Ende November 2025 hat die Foundation den Raspberry Pi Imager 2.0 veröffentlicht, inzwischen ist die Version 2.0.11 aktuell (bzw. 2.0.11.1 als Hotfix). Unter der Haube hat sich seitdem viel getan, vor allem aber sieht das Programm komplett anders aus. Die wichtigsten Änderungen im Überblick:

• Assistent statt Einzelfenster: Ihr klickt euch nun Schritt für Schritt durch Gerät, Betriebssystem, Speichermedium, Anpassungen und Schreibvorgang.
• Anpassungen gut sichtbar: Der früher versteckte Dialog für die „erweiterten Optionen“ (ich sag nur Strg+Umschalt+X) ist jetzt ein regulärer Schritt im Assistenten.
• Standort per Hauptstadt: Statt Ländercodes wählt ihr eine Hauptstadt aus, der Imager leitet daraus Zeitzone, Tastaturlayout und das WLAN-Regulierungsland ab.
• Schnittstellen per Mausklick: I2C, SPI, 1-Wire, die serielle Schnittstelle und den USB-Gadget-Modus (der Pi meldet sich am USB-Port als Netzwerkgerät, SSH klappt dann direkt übers Kabel) schaltet ihr direkt im Imager ein, der Umweg über raspi-config entfällt.
• Raspberry Pi Connect: Ihr könnt euch schon beim Schreiben mit eurem Connect-Konto anmelden, der Pi taucht dann nach dem ersten Boot direkt in der Fernwartung auf. Seit Version 2.0.10 klappt das auch mit Connect for Organisations.
• Barrierefreiheit: Die Oberfläche lässt sich komplett per Tastatur bedienen und ist für Screenreader beschriftet.
• Strengere Verifikation: Der Imager zwingt das Betriebssystem, geschriebene Blöcke tatsächlich zu bestätigen. Das kann das Schreiben etwas verlängern, dafür ist das Ergebnis verlässlicher.

Es ist aber auch etwas weggefallen: Eigene Image-Dateien lassen sich zwar weiterhin schreiben, aber nicht mehr mit Hostname, WLAN und Co. vorkonfigurieren. Die Entwickler begründen das damit, dass diese Funktion nie offiziell unterstützt wurde. Anpassen lassen sich nur noch Images, die entsprechend gekennzeichnet sind.

Wer bisher etwa ein selbst gebautes Image mit dem Imager vorkonfiguriert hat, der muss sich also einen anderen Weg suchen – oder greift zum CLI-Modus, den ich weiter unten vorstelle. Entwarnung gibt es dagegen bei den SSH-Schlüsseln: Die zum Start von 2.0 gestrichene Unterstützung für mehrere Schlüssel ist inzwischen wieder zurück.

Raspberry Pi Imager unter Linux installieren

Jetzt wird es für uns Linux-User spannend, denn hier unterscheiden sich die Distributionen deutlich. Die offizielle Download-Seite bietet für Linux ein AppImage an. Auf GitHub gibt es zusätzlich .deb-Pakete für amd64, arm64 und armhf sowie eine reine Kommandozeilenversion. Was eure Distribution mitbringt, ist dagegen eine andere Geschichte.

Arch Linux: aktuell direkt aus extra

Arch-User haben es wie so oft am bequemsten: Der Imager liegt im offiziellen Repository extra und ist dort aktuell (zum Zeitpunkt dieses Artikels die Version 2.0.11.1). Ein AUR-Helper ist nicht nötig, ein einfacher Aufruf von pacman genügt, und schon steht der Imager in eurem Anwendungsmenü bereit:

$ sudo pacman -S rpi-imager

Das Arch-Paket bringt eine Polkit-Regel mit. Startet ihr den Imager ganz normal aus dem Anwendungsmenü, fordert er sich über pkexec selbst die nötigen Rechte an – ihr gebt also nur euer Passwort im Polkit-Dialog ein. Wer einen AUR-Helper wie Paru oder Yay nutzt, findet im AUR zudem rpi-imager-git – normalerweise braucht ihr das nicht.

Ubuntu: Finger weg von Universe und Snap

Bei Ubuntu lauert dagegen eine Falle, über die keine der gängigen Anleitungen ein Wort verliert. Ein sudo apt install rpi-imager funktioniert zwar, installiert aber selbst unter Ubuntu 26.04 noch die uralte Version 1.8.5 aus universe. Auch das Snap im Snap Store steht bei Version 1.9.6.

Beide Pakete bekommen also nichts von dem neuen Assistenten, Raspberry Pi Connect oder den Fehlerkorrekturen der letzten Monate mit. Ubuntu-User greifen daher besser zum AppImage, zum Flatpak (beides weiter unten) oder zum offiziellen .deb-Paket von GitHub. Ersetzt <version> im Befehl durch die Versionsnummer der heruntergeladenen Datei:

$ sudo apt install ./rpi-imager_<version>_amd64.deb

Habt ihr schon eine alte Version per apt oder Snap installiert, dann werft sie vorher runter, damit ihr im Anwendungsmenü nicht zwei Imager nebeneinander stehen habt. Sonst startet ihr im Zweifel versehentlich die alte Version und wundert euch über die fehlenden Funktionen.

$ sudo apt remove rpi-imager
$ sudo snap remove rpi-imager

AppImage: der offizielle Weg für alle Distributionen

Das AppImage funktioniert unabhängig von der Distribution – also auch unter Fedora, openSUSE und Co. Ladet es von der offiziellen Download-Seite herunter, macht es ausführbar und startet es, eine Installation ist nicht nötig. Den Platzhalter <version> ersetzt ihr auch hier durch die Versionsnummer aus dem Dateinamen:

$ chmod +x Raspberry_Pi_Imager-v<version>-desktop-x86_64.AppImage
$ ./Raspberry_Pi_Imager-v<version>-desktop-x86_64.AppImage

Beim ersten Start ohne Root-Rechte meckert der Imager und bietet euch die Schaltfläche Autorisierung installieren an. Klickt ihr darauf, legt er (nach Eingabe eures Passworts) eine Polkit-Regel unter /etc/polkit-1/actions/ ab, die genau für diesen Pfad des AppImages gilt. Danach holt er sich die Rechte bei jedem Start selbst.

Verschiebt ihr das AppImage später in einen anderen Ordner, müsst ihr die Autorisierung erneut einrichten. Wer lieber ohne dauerhafte Regel arbeitet, startet das AppImage mit sudo. Dabei gibt es einen Stolperstein, auf den Michael Kofler in seinem Artikel hinweist: sudo sucht nicht im aktuellen Verzeichnis, ihr müsst also einen Pfad angeben.

$ sudo ./Raspberry_Pi_Imager-v<version>-desktop-x86_64.AppImage

Ohne das ./ gibt es nur ein „Befehl nicht gefunden“. Kurios: Genau diesen Befehl ohne Pfad schlägt euch der Imager im Dialog zu den fehlenden Rechten selbst vor. Unter Ubuntu 24.04 lauert zudem eine zweite Falle: Dort stürzt das AppImage direkt beim Start ab, weil Qt eine Bibliothek für X11 fehlt. Im Terminal sieht das so aus:

$ ./Raspberry_Pi_Imager-v2.0.11-desktop-x86_64.AppImage 
Platform: Linux 7.0.0-38-generic (x86_64)
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugin.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "/tmp/.mount_RaspbedIOBeG/usr/plugins/platforms" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vkkhrdisplay, vnc, wayland-brcm, wayland-egl, wayland, xcb.

Abgebrochen (Speicherabzug geschrieben)

Abhilfe schafft das Paket libxcb-cursor0, das ihr ganz normal über die Paketverwaltung nachinstalliert. Danach startet der Imager auch unter Ubuntu 24.04 ohne Murren. Unter Ubuntu 26.04 tritt das Problem nicht mehr auf. Das früher oft empfohlene Paket libfuse2t64 war bei meinem Test dagegen nicht mehr nötig.

$ sudo apt install libxcb-cursor0

Übrigens: Der Hotfix 2.0.11.1 ist bisher nur für Windows, macOS und als .deb-Paket erschienen, als AppImage ist 2.0.11 die neueste Version. Das ist aber kein Beinbruch, denn der Hotfix korrigiert lediglich einen Fehler bei der Anmeldung an Raspberry Pi Connect. Wer Connect nicht nutzt, verpasst also nichts.

Flatpak: bequem, aber nicht vom Hersteller verifiziert

Auf Flathub liegt der Imager als org.raspberrypi.rpi-imager in der aktuellen Version bereit. Das Flatpak bekommt vollen Zugriff auf alle Geräte und spricht UDisks2 an, um die Speichermedien zu beschreiben. Nett für Datenschutzbewusste: Es wird ohne Telemetrie gebaut. Installiert wird es wie gewohnt:

$ flatpak install flathub org.raspberrypi.rpi-imager

Beachtet allerdings, dass die App auf Flathub nicht als verifiziert markiert ist. Flathub nennt zwar Raspberry Pi Ltd als Entwickler, ob die Raspberry Pi das Paket selbst pflegt, lässt sich so aber nicht erkennen. In der Regel ist das kein Problem, ihr solltet es aber wissen.

Raspberry Pi OS

Wer den Imager direkt auf einem Raspberry Pi nutzen möchte, etwa um eine zweite Karte oder eine SSD für einen anderen Pi vorzubereiten, der installiert ihn unter Raspberry Pi OS ganz klassisch aus den Paketquellen. Hier stammt das Paket direkt aus den Quellen der Foundation, anders als bei Ubuntu:

$ sudo apt update && sudo apt install rpi-imager

Ganz ohne zweiten Rechner kommt ihr beim Raspberry Pi 4 und 5 aus: Deren Bootloader kann per Netzwerk-Installation eine abgespeckte Version des Imagers aus dem Netz laden, mit der ihr dann direkt eine SD-Karte oder SSD im Pi beschreibt. Mit Version 2.0.11 wurde dieser Netzwerk-Installer spürbar überarbeitet und verschlankt.

Warum braucht der Imager überhaupt Root-Rechte?

Unter Windows und macOS fällt es kaum auf, unter Linux dagegen schon: Der Imager schreibt direkt auf das Blockgerät, also etwa /dev/sdb oder /dev/mmcblk0, und das darf ein normaler Benutzer nicht. Die Version 2 kümmert sich deshalb selbst darum, sich über pkexec die nötigen Rechte zu holen.

Voraussetzung ist eine passende Polkit-Regel. Beim Arch-Paket und dem offiziellen .deb wird diese mitinstalliert, beim AppImage legt ihr sie über Autorisierung installieren an. Startet ihr den Imager per sudo oder pkexec, landen Einstellungen und Download-Cache trotzdem in eurem Home-Verzeichnis und nicht in /root, denn der Imager erkennt den aufrufenden Benutzer.

Kleiner Tipp für Aufräumer: Die vom AppImage angelegten Regeln heißen com.raspberrypi.rpi-imager.appimage-<hash>.policy und liegen unter /etc/polkit-1/actions/. Löscht ihr das AppImage, könnt ihr die dazugehörige Regel dort von Hand entfernen. Auch auf Distributionen mit schreibgeschütztem /usr wie Fedora Silverblue klappt das, da der Imager bewusst nach /etc schreibt.

So schreibt ihr ein Image mit dem Raspberry Pi Imager

Die eigentliche Bedienung ist mit dem neuen Assistenten schnell erklärt. Ihr arbeitet euch von oben nach unten durch fünf Schritte und könnt jederzeit einen Schritt zurückgehen, falls ihr euch verklickt habt. Geschrieben wird erst ganz am Ende nach einer ausdrücklichen Sicherheitsabfrage, vorher passiert mit eurer SD-Karte also nichts:

1. Gerät wählen: Zuerst sagt ihr dem Imager, für welches Modell das Image gedacht ist, etwa Raspberry Pi 5 oder Raspberry Pi Zero 2 W. Die Liste der Betriebssysteme wird danach passend gefiltert.
2. Betriebssystem wählen: Hier sucht ihr euch Raspberry Pi OS (mit oder ohne Desktop, 32 oder 64 Bit) oder eine der vielen anderen Distributionen aus. Über Eigenes Image wählt ihr ein lokal gespeichertes Image aus.
3. Speichermedium wählen: Jetzt kommt die SD-Karte oder der USB-Stick. Mehr dazu gleich im nächsten Abschnitt.
4. Anpassen: Hostname, Standort, Benutzer und Passwort, WLAN, SSH (per Passwort oder Public Key), Raspberry Pi Connect sowie Schnittstellen wie I2C und SPI. Je nach Betriebssystem schreibt der Imager diese Einstellungen als firstrun.sh, als cloud-init-Konfiguration oder in einem weiteren Format auf die Boot-Partition.
5. Schreiben: Nach einer Sicherheitsabfrage lädt der Imager das Image herunter, schreibt und verifiziert es. Einmal heruntergeladene Images landen im Cache, beim nächsten Schreiben desselben Images geht es deutlich schneller.

Wer mehrere Pis auf einmal einrichten möchte, der freut sich über die Funktion zum Schreiben einer weiteren Karte am Ende des Assistenten. Damit schreibt ihr dasselbe Image samt Anpassungen gleich noch einmal, ohne euch erneut durch alle Schritte klicken zu müssen. Denkt dann aber daran, den Hostnamen anzupassen.

Mein Tipp für den Headless-Betrieb: Hinterlegt direkt euren öffentlichen SSH-Schlüssel statt eines Passworts. Dann könnt ihr euch sofort nach dem ersten Boot per ssh auf den Pi schalten, ohne jemals ein Passwort eintippen zu müssen. Wer von mehreren Rechnern aus zugreift, trägt einfach mehrere Schlüssel ein.

Setzt ihr einen Pi mit gleichem Hostnamen neu auf, meckert SSH beim nächsten Login über einen geänderten Host-Schlüssel. In diesem Fall steckt kein Angriff dahinter, denn das frisch installierte System hat schlicht neue Schlüssel erzeugt. Mit einem einzigen Befehl ist das Problem schnell behoben.

Achtung: das richtige Laufwerk erwischen

Der wohl wichtigste Punkt überhaupt: Der Imager überschreibt das gewählte Speichermedium komplett und prüft nicht, ob es noch Daten enthält. Michael Kofler kritisiert zu Recht, dass die Symbole für SD-Karten und USB-Geräte in der Auswahl verwirrend sein können und in der Zusammenfassung nicht der konkrete Gerätename wie /dev/sde erscheint.

Klar, der Imager blendet Systemlaufwerke standardmäßig aus, doch eine externe Backup-Platte am USB-Port ist für ihn eben auch nur ein Wechseldatenträger. Unter Linux habt ihr allerdings ein einfaches Mittel, um auf Nummer sicher zu gehen: Schaut vor und nach dem Einstecken der SD-Karte mit lsblk nach, welches Gerät neu hinzugekommen ist.

$ lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
NAME          SIZE MODEL                TRAN   MOUNTPOINTS
sda           4,5T WDC WD50NDZW-11BCSS1 usb    
└─sda1        4,5T                             /mnt/backup
sdb         117,2G Speed Line           usb    
├─sdb1        198K                             
├─sdb2        2,8M                             
└─sdb3        4,6G                             
zram0         3,8G                             [SWAP]
nvme0n1       3,6T CT4000P3PSSD8        nvme   
├─nvme0n1p1   512M                      nvme   /boot
└─nvme0n1p2   3,6T                      nvme   /var/log
                                               /var/cache/pacman/pkg
                                               /home
                                               /.snapshots
                                               /

In meinem Beispiel ist die Sache eindeutig: Unter sdb steckt der USB-Stick „Speed Line“ mit gut 117 GByte und den Reste eines alten ISO-Images. Bei sda handelt es sich dagegen um die externe Backup-Platte, die unter /mnt/backup eingehängt ist. Beide hängen laut Spalte TRAN am USB-Port.

Genau hier lauert die Gefahr, denn für den Imager sind beide Laufwerke gleichermaßen Wechseldatenträger. Größe und Modellname verraten euch, welches Gerät das richtige ist. Zieht zur Sicherheit am besten alle externen Festplatten ab, bevor ihr den Imager startet. Ein paar Sekunden Vorsicht sind allemal besser als eine plattgebügelte Backup-Platte.

Seit Version 2.0.11 sperrt der Imager unter Linux das Laufwerk übrigens exklusiv, solange er darauf schreibt. Kein anderes Programm kann dann gleichzeitig auf die Karte zugreifen und euch das frisch geschriebene Image zerschießen. Vor einer falschen Auswahl schützt euch das natürlich nicht, da hilft nur ein prüfender Blick.

Raspberry Pi Imager im Terminal: der CLI-Modus

Was die meisten Anleitungen nicht erwähnen: Der Imager lässt sich auch komplett ohne grafische Oberfläche nutzen. Das ist praktisch für Skripte, für die Arbeit per SSH oder wenn ihr mehrere Karten vorbereiten wollt. Den CLI-Modus aktiviert ihr mit --cli, danach folgen Image und Zielgerät:

$ sudo rpi-imager --cli raspios.img.xz /dev/sdb

Das Image darf komprimiert sein (seit 2.0.11 auch als mehrteiliges .img.zst), und statt einer lokalen Datei akzeptiert der Imager auch eine HTTP- oder HTTPS-Adresse. Eine Übersicht aller Optionen liefert rpi-imager --cli --help, außerdem bringt das Arch-Paket eine Manpage mit. Die in meinen Augen nützlichsten Optionen:

• --sha256 <hash> prüft vor dem Schreiben, ob das Image der erwarteten Prüfsumme entspricht.
• --disable-verify überspringt die Verifikation nach dem Schreiben (spart Zeit, kostet Sicherheit).
• --first-run-script <datei> legt ein eigenes firstrun.sh auf das Image.
• --cloudinit-userdata <datei> und --cloudinit-networkconfig <datei> schreiben eigene cloud-init-Konfigurationen mit auf die Karte.
• --disable-eject verhindert, dass der Datenträger nach dem Schreiben ausgeworfen wird – praktisch, wenn ihr danach noch Dateien auf die Boot-Partition kopieren wollt.
• --quiet gibt nur noch Fehler aus, ideal für Skripte.

Gerade die cloud-init-Optionen sind interessant: Damit habt ihr im Terminal mehr Möglichkeiten als in der grafischen Oberfläche, und das auch für Images, die der Imager im Assistenten nicht mehr anpasst. Für Server ohne Qt-Oberfläche gibt es auf GitHub zudem ein eigenes Paket rpi-imager-cli sowie ein CLI-AppImage, bei denen der Schalter --cli entfällt.

Eigene Image-Listen mit –repo

Noch ein Schmankerl für Bastler, Vereine und Schulen: Mit --repo bringt ihr dem Imager eine eigene Liste von Images bei. Statt die Server von Raspberry Pi abzufragen, liest er dann eine JSON-Datei ein, die entweder im Netz oder lokal auf eurer Platte liegt. Das Format ist im Repository unter doc/json-schema beschrieben.

$ rpi-imager --repo https://example.org/os_list.json

So könnt ihr etwa einem Verein oder einer Schulklasse einen Imager mitgeben, in dem nur die eigenen, vorbereiteten Images auftauchen. Legt euch dafür einfach einen eigenen Starter im Anwendungsmenü an, der den Imager mit dem passenden Parameter aufruft. Den Rest erledigt der Imager dann wie gewohnt.

Telemetrie abschalten

Standardmäßig meldet der Imager bei jedem Schreibvorgang anonym an Raspberry Pi, welches Image ihr ausgewählt habt, dazu die Imager-Version, euer Host-Betriebssystem, die Architektur und die Spracheinstellung. Laut README werden dabei nur Zähler gespeichert, die aggregierten Daten sind öffentlich unter rpi-imager-stats.raspberrypi.com einsehbar.

Wer das trotzdem nicht möchte, schaltet die Statistik in den App-Optionen ab oder startet den Imager einmal mit dem Parameter --disable-telemetry, der die Einstellung dauerhaft speichert. Wie oben erwähnt, ist die Telemetrie beim Flatpak ohnehin nicht einkompiliert. Dort müsst ihr euch also um nichts kümmern.

Häufige Probleme unter Linux

Der Imager meldet, er laufe nicht als Root. Beim AppImage klickt ihr auf Autorisierung installieren oder startet es mit sudo ./…. Bei Distributionspaketen prüft ihr, ob unter /usr/share/polkit-1/actions/ die Datei com.raspberrypi.rpi-imager.policy liegt. Fehlt sie, installiert das Paket neu oder startet den Imager testweise mit sudo.

Das AppImage startet nicht. Prüft zuerst, ob das Ausführbar-Bit gesetzt ist (chmod +x). Unter Ubuntu 24.04 fehlt zudem libxcb-cursor0, ohne das das AppImage direkt beim Start abstürzt. Startet das AppImage testweise im Terminal, dann seht ihr die Fehlermeldung und wisst, welches Puzzlestück noch fehlt.

Ubuntu zeigt die alte Oberfläche. Dann habt ihr die Version aus apt oder dem Snap Store erwischt, die beide noch auf dem Stand von 1.x hängen. Deinstalliert sie und greift stattdessen zum .deb von GitHub, zum AppImage oder zum Flatpak. Danach begrüßt euch auch unter Ubuntu der neue Assistent.

Die SD-Karte taucht nicht auf. Schaut mit lsblk, ob der Kartenleser die Karte überhaupt erkennt. Manche Kartenleser zeigen erst nach erneutem Einstecken ein Gerät an, andere mögen bestimmte Karten schlicht nicht. Taucht die Karte auch in lsblk nicht auf, liegt das Problem nicht beim Imager.

Das Schreiben dauert ewig. Die Verifikation liest das komplette Image nach dem Schreiben noch einmal von der Karte. Bei langsamen Karten oder USB-2-Kartenlesern kann das dauern. Eine schnellere Karte hilft hier mehr als das Abschalten der Prüfung. Schlägt die Verifikation fehl, solltet ihr eure Karte auf Fehler prüfen.

Defekte USB-Sticks oder microSD-Karten. Zeigt der Imager beim Schreiben den Hinweis „Limited by storage device speed“ an, bremst das Speichermedium den Vorgang wesentlich aus. Bei nur wenigen MB/s steckt oft ein altersschwacher Stick oder eine defekte Karte dahinter. Prüft den Datenträger dann auf Fehler, bevor ihr euch über eine abgebrochene Verifikation wundert.

Alternativen zum Raspberry Pi Imager

Natürlich muss es nicht immer der Imager sein. Wer ein Image schon heruntergeladen hat, der kommt unter Linux auch mit Bordmitteln ans Ziel – etwa mit dd, mit der Funktion Laufwerksabbild wiederherstellen in Gnome Disks oder dem GTK4-Tool Impression. Dann fehlt allerdings die komfortable Vorkonfiguration, Hostname, SSH und WLAN richtet ihr von Hand ein.

Wollt ihr umgekehrt ein bestehendes System sichern und das Image möglichst klein halten, dann schaut euch mal PiShrink an. Damit schrumpft ihr ein ausgelesenes Image auf die tatsächlich belegte Größe zusammen und könnt es später wieder mit dem Imager auf eine Karte schreiben.

Besser als dd, aber auch nicht Pflicht

Alles in allem war das Upgrade auf den Raspberry Pi Imager 2.0 in meinen Augen ein klarer Fortschritt. Der Assistent führt auch Einsteiger sicher durch die Einrichtung, und für Linux-User wurde gerade beim Thema Root-Rechte einiges an Gefrickel beseitigt. Arch-User installieren das Programm einfach aus extra und sind fertig.

Ubuntu-User sollten dagegen unbedingt die Paketquellen und den Snap Store links liegen lassen und zum offiziellen Paket greifen. Und wer gerne im Terminal arbeitet, der sollte sich den CLI-Modus mit den cloud-init-Optionen einmal genauer ansehen. Wie bereitet ihr eure SD-Karten vor? Nutzt ihr den Imager oder schwört ihr noch auf dd?