Raspberry Pi Netboot – der Pi ohne SD-Karte

Passende Hardware im Überblick

Boards – Server und Clients:
Raspberry Pi 5 mit 16 GB RAM als Boot-Server für viele Clients (Link)*
Raspberry Pi 5 mit 8 GB RAM – die Empfehlung für den Server (Link)*
Raspberry Pi 5 mit 4 GB RAM als kartenloser Client (Link)*
Raspberry Pi 4 Starter-Set – Pi 4 kann Netboot ab Werk (Link)*
Beelink S12 Pro N100 – wenn der Server mehr leisten soll (Link)*

Speicher für den Server – hier liegen alle Systeme:
Geekworm X1001 M.2-HAT für den Pi 5 (Link)*
Offizieller PCIe-M.2-HAT (Link)*
Intenso M.2 NVMe SSD 500 GB (Link)*
Crucial P310 NVMe SSD 500 GB – die schnellere Wahl (Link)*
SanDisk Extreme Portable SSD 1 TB per USB (Link)*
SanDisk Extreme A2 128 GB für die Ersteinrichtung (Link)*

Netzwerk und Strom – der Server muss durchlaufen:
Waveshare PoE-HAT für den Pi 5 – Strom über das LAN-Kabel (Link)*
Waveshare PoE-HAT für den Pi 4 (Link)*
GeeekPi P33 mit PoE und NVMe in einem (Link)*
Offizielles 27-W-Netzteil für den Pi 5 (Link)*
Geekworm X1200 USV – hält den Server bei Stromausfall am Leben (Link)*

Kurz gesagt: Kann ein Raspberry Pi ohne SD-Karte aus dem Netz starten?

Die Kurzfassung:

• Ja, ab dem Pi 3: Raspberry Pi Netboot holt Bootdateien per TFTP und das Wurzeldateisystem per NFS aus dem Netzwerk. Im Client steckt danach keine Speicherkarte mehr.
• Nur mit Kabel: Der Bootvorgang läuft ausschließlich über die eingebaute Ethernet-Schnittstelle. WLAN und USB-Netzwerkadapter werden vom Bootloader nicht unterstützt.
• Zwei Zutaten: Ein dnsmasq im Proxy-DHCP-Modus als TFTP-Server und ein nfs-kernel-server für das Wurzeldateisystem. Der Router darf dabei weiter die Adressen vergeben.
• Eine Einstellung am Client: Beim Pi 4 und 5 genügt in raspi-config unter Advanced Options die Boot Order „Network Boot" – das schreibt BOOT_ORDER=0xf21 ins EEPROM.
• Der Gewinn: Kein Kartenverschleiß, ein zentral gepflegtes System, und ein zerschossener Client ist durch Kopieren eines Verzeichnisses ersetzt.
• Der Preis: Fällt der Server aus, steht die ganze Flotte. Für einen einzelnen Pi ist eine SSD der einfachere Weg zur Kartenfreiheit.

Was Raspberry Pi Netboot ist und wie der Start abläuft

Beim gewohnten Start liest der Bootloader die Firmware-Dateien von der Speicherkarte, übergibt an den Kernel, und der hängt die zweite Partition als Wurzeldateisystem ein. Beim Netzwerkstart passiert genau dasselbe – nur kommen beide Bestandteile von einem anderen Rechner im gleichen LAN.

Der Ablauf ist erstaunlich schlicht. Der Client schickt eine DHCP-Anfrage, die sich als PXE-Client zu erkennen gibt. Der Server antwortet nicht nur mit einer Adresse, sondern zusätzlich mit der Kennung „Raspberry Pi Boot" in der Hersteller-Option 43. Erst diese Zeichenkette sagt dem Bootloader, dass hier ein Bootserver steht. Danach lädt er die Firmware- und Kerneldateien per TFTP, liest die cmdline.txt und findet dort statt einer Partition den Eintrag root=/dev/nfs mit der Adresse der NFS-Freigabe. Der Kernel mountet das Wurzeldateisystem also über das Netzwerk – und ab da fühlt sich das System an wie jedes andere Raspberry Pi OS.

Die Unterschiede zwischen den Modellen betreffen nur den Einstieg. Beim Pi 3 Model B muss der Netzwerkstart einmalig über ein OTP-Bit freigeschaltet werden, das der Zusatz program_usb_boot_mode=1 in der config.txt setzt; das Modell 3B+ bringt die Funktion ab Werk mit. Beim Pi 4 und Pi 5 steckt der Netzwerkstart im Bootloader-EEPROM und wird schlicht über die Boot-Reihenfolge aktiviert.

Damit jeder Client seine eigenen Dateien bekommt, stellt der Bootloader den Dateinamen ein geräteeigenes Verzeichnis voran. Ab Werk ist das die Seriennummer der Platine. Weil beim Pi 4 und 5 die MAC-Adresse nicht mehr aus der Seriennummer abgeleitet wird, lässt sich dieses Präfix per TFTP_PREFIX auch auf die MAC-Adresse oder auf eine feste Zeichenkette umstellen – praktisch, wenn der Server die Verzeichnisse automatisch anlegen soll.

Raspberry Pi Netboot einrichten – Schritt für Schritt

Für den Aufbau braucht es zwei Geräte: einen Server, der dauerhaft läuft, und mindestens einen Client. Beide hängen per Kabel am selben Netz. Die Speicherkarte wird nur für die Ersteinrichtung des Clients gebraucht.

1. Client identifizieren: Auf dem Client mit aufgesetzter Karte die Kennungen notieren – grep Serial /proc/cpuinfo liefert die Seriennummer, ethtool -P eth0 die MAC-Adresse. Beide erscheinen auch auf dem Diagnosebildschirm des Bootloaders, wenn man den Pi ohne Bootmedium startet.
2. Netzwerkstart am Client freischalten: sudo raspi-config aufrufen, dort Advanced Options, dann Boot Order und Network Boot wählen. Nach dem Neustart bestätigt vcgencmd bootloader_config den Wert BOOT_ORDER=0xf21.
3. Server vorbereiten: Der Server bekommt eine feste IP-Adresse – sonst zeigen die Bootdateien der Clients irgendwann ins Leere. Danach sudo apt install dnsmasq nfs-kernel-server rsync.
4. Wurzeldateisystem anlegen: Eine Kopie des Server-Systems dient als Vorlage für den Client: sudo mkdir -p /nfs/client1 und sudo rsync -xa --progress --exclude /nfs / /nfs/client1. Anschließend im Verzeichnis per chroot die SSH-Hostschlüssel neu erzeugen, damit nicht zwei Geräte dieselben Schlüssel benutzen.
5. dnsmasq als Proxy-DHCP konfigurieren: In /etc/dnsmasq.conf gehören die Zeilen port=0, dhcp-range=192.168.178.255,proxy, log-dhcp, enable-tftp, tftp-root=/tftpboot und pxe-service=0,"Raspberry Pi Boot". Der Proxy-Modus ist der entscheidende Kniff: Die Adressvergabe bleibt beim Router, dnsmasq ergänzt nur die Boot-Information.
6. Bootdateien bereitstellen: sudo mkdir /tftpboot, dann den Inhalt von /boot/firmware dorthin kopieren. Für mehrere Clients bekommt jeder ein Unterverzeichnis mit seiner Seriennummer als Namen.
7. NFS freigeben: In /etc/exports die Zeilen /nfs/client1 *(rw,sync,no_subtree_check,no_root_squash) und /tftpboot *(rw,sync,no_subtree_check,no_root_squash) eintragen, danach sudo systemctl restart nfs-kernel-server.
8. Startparameter anpassen: In /tftpboot/cmdline.txt alles ab root= ersetzen durch root=/dev/nfs nfsroot=192.168.178.10:/nfs/client1,vers=3 rw ip=dhcp rootwait und einen eventuellen init=-Eintrag entfernen. In /nfs/client1/etc/fstab die beiden Zeilen mit mmcblk0 löschen und stattdessen die TFTP-Freigabe als /boot/firmware eintragen.
9. Karte ziehen und starten: Client ohne Speicherkarte einschalten. Der erste Versuch braucht manchmal zwei Anläufe – wenn nichts passiert, hilft ein journalctl -f auf dem Server, weil dnsmasq jede angeforderte Datei protokolliert.

BOOT_ORDER verstehen: die Boot-Reihenfolge im EEPROM

Der Bootloader des Pi 4, Pi 5 und der Compute Modules liest eine hexadezimale Ziffernfolge und arbeitet sie von rechts nach links ab. Jede Ziffer steht für eine Bootquelle. Wer das einmal verstanden hat, konfiguriert jedes Startverhalten selbst – zum Beispiel „erst Netz, dann NVMe, dann von vorn".

Der Standardwert lautet 0xf41: erst SD-Karte, dann USB, dann von vorn. 0xf21 ergänzt den Netzwerkstart nach der Karte, 0xf12 versucht zuerst das Netz und fällt auf die Karte zurück. Gesetzt wird das über sudo rpi-eeprom-config --edit. Ergänzend lohnen sich zwei Werte: NET_BOOT_MAX_RETRIES legt fest, wie oft der Netzwerkstart wiederholt wird, bevor die nächste Quelle drankommt, und TFTP_IP setzt den Bootserver fest, wenn der Router weiterhin allein DHCP machen soll.

Netboot, USB-Boot oder HTTP-Boot – was wann passt

Der Netzwerkstart ist nicht die einzige Antwort auf den Kartenverschleiß, und für viele Aufbauten auch nicht die naheliegendste.

Als Faustregel: Bis zu zwei dauerhaft laufende Geräte fährt man mit einer NVMe-SSD oder einem USB-Datenträger schneller und ruhiger. Ab drei bis vier gleichartigen Geräten kippt die Rechnung, weil jede Aktualisierung sonst mehrfach anfällt.

Wofür sich der Netzwerkstart im Alltag lohnt

Berichte aus der Community zeigen ein klares Muster: Netboot glänzt überall dort, wo mehrere Geräte dasselbe tun sollen und niemand Lust hat, sie einzeln anzufassen.

• Anzeigeflotten: Mehrere Kiosk-Displays im Haus oder im Betrieb booten ein identisches System. Eine Änderung auf dem Server erreicht nach dem Neustart alle Bildschirme.
• Schulungs- und Werkstattplätze: Wer regelmäßig frische Systeme braucht, kopiert einfach ein Verzeichnis zurück, statt Karten zu beschreiben.
• Cluster und Testaufbauten: Knoten lassen sich hinzufügen, ohne dass für jeden ein Datenträger beschafft und bespielt werden muss.
• Geräte an unzugänglichen Orten: Ein Pi hinter dem Fernseher oder unter der Decke muss nie wieder wegen einer Speicherkarte abgebaut werden.
• Geräte mit hoher Schreiblast: Wo bisher Karten im Jahresrhythmus starben, liegt die Last nun auf der Server-SSD, die dafür gebaut ist.

Für den Server bietet sich ein ohnehin durchlaufendes Gerät an – etwa der NAS-Pi. Er sollte auf SSD laufen, an einer USV hängen und im Backup auftauchen, denn er trägt jetzt die Systeme aller Clients.

Fehler und Stolpersteine beim Netzwerkstart

• WLAN erwarten: Der Bootloader kennt nur die eingebaute Ethernet-Schnittstelle. Ein Netzwerkstart über Funk oder über einen USB-Adapter funktioniert grundsätzlich nicht.
• Managed Switches mit Spanning Tree: Blockiert der Switch die ersten Sekunden nach dem Verbinden, ist der Bootversuch vorbei, bevor der Port durchschaltet. Das Abschalten der STP-Behandlung am betreffenden Port löst das Problem.
• Falsche Kennung im DHCP: Fehlt in der Antwort die Zeichenkette „Raspberry Pi Boot", ignoriert der Client den Server. Wenn nichts geschieht, gehört ein Blick in das Protokoll von dnsmasq an den Anfang der Suche.
• Zwei Clients auf einem Verzeichnis: Schreibende Systeme brauchen je ein eigenes Wurzelverzeichnis. Nur ein schreibgeschütztes System mit Overlay darf gemeinsam genutzt werden.
• Doppelte SSH-Hostschlüssel: Wer das Serversystem kopiert und die Schlüssel nicht neu erzeugt, bekommt beim Zugriff ohne Monitor Warnungen und Verwechslungen.
• Vergessene fstab-Einträge: Bleiben die Zeilen mit mmcblk0 stehen, hängt der Start beim Warten auf eine Karte, die gar nicht da ist – ein Fall, der leicht mit anderen Startproblemen verwechselt wird.
• Server ohne Reserve: Ein Neustart des Servers friert alle laufenden Clients ein. Wartungsfenster gehören eingeplant, sobald mehr als ein Gerät daran hängt.

Häufige Fragen zum Netzwerkstart des Raspberry Pi

Welche Modelle können vom Netzwerk starten?
Der Pi 3 Model B nach einmaliger Freischaltung des OTP-Bits, das Modell 3B+ ab Werk sowie Pi 4, Pi 5 und die Compute Modules über die Boot-Reihenfolge im EEPROM. Der Zero und der Zero 2 W haben keine Ethernet-Schnittstelle und fallen damit heraus.

Verträgt sich der Bootserver mit einer FritzBox?
Ja. Im Proxy-DHCP-Modus vergibt weiterhin der Router die Adressen; dnsmasq antwortet nur zusätzlich mit der Boot-Information. Am Router selbst ist keine Änderung nötig.

Wie schnell startet ein Client über das Netz?
Im Gigabit-Netz liegt der Start in der Größenordnung eines Kartenstarts. Wie flüssig sich das System danach anfühlt, hängt vor allem an der Platte im Server – eine SSD ist dort Pflicht.

Können sich mehrere Clients ein System teilen?
Schreibgeschützt ja, und für identische Anzeigeflotten ist das sogar die eleganteste Lösung. Sobald ein Client schreiben können muss, braucht er sein eigenes Verzeichnis.

Was passiert, wenn der Server ausfällt?
Laufende Clients bleiben stehen, sobald sie auf das Dateisystem zugreifen wollen, und neue starten gar nicht erst. Deshalb gehören USV und Backup zwingend zum Aufbau.

Wie finde ich heraus, woran der Start hängt?
Den Client ohne Bootmedium starten und auf den Diagnosebildschirm schauen: Er zeigt die Boot-Reihenfolge, den Verbindungsstatus, die vergebene IP-Adresse und die Adresse des TFTP-Servers.

Was ist der Unterschied zur Netzwerkinstallation?
Die Netzwerkinstallation lädt per HTTP eine Kurzfassung des Imagers auf den Pi, um damit ein System auf ein lokales Medium zu schreiben. Der Netzwerkstart dagegen betreibt den Pi dauerhaft vom Server.

Fazit

Raspberry Pi Netboot ist keine Bastelei für den Einzelrechner, sondern ein Verwaltungswerkzeug. Unsere klare Empfehlung fällt deshalb zweigeteilt aus: Wer einen einzigen Pi von der Speicherkarte befreien will, nimmt eine SSD – das ist in zwanzig Minuten erledigt und hat keinen zentralen Schwachpunkt. Wer dagegen drei, fünf oder zwanzig gleichartige Geräte betreibt, sollte den Nachmittag in einen Bootserver investieren. Danach ist ein defekter Client kein Vorfall mehr, sondern ein kopiertes Verzeichnis, und eine Aktualisierung erreicht die ganze Flotte auf einen Schlag. Wichtig bleibt nur die eine Konsequenz: Der Server trägt jetzt alles – er gehört auf SSD, an eine unterbrechungsfreie Stromversorgung und ins Sicherungskonzept.

* = Affiliate Link (raspi-config.de ist Teilnehmer des Partnerprogramms von Amazon EU, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu Amazon.de Werbekostenerstattung verdient werden kann.)