Raspberry Pi über das Netzwerk booten

In diesem Artikel zeige ich euch wie ihr den Raspberry Pi über das Netzwerk booten könnt. Neben der USB Bootoption ist das die große Neuerung. Endlich ist man nicht mehr auf die SD Karten angewiesen, die gerade bei stärkerer Beanspruchung oft als das schwächste Bauteil durch Ausfälle aufgezeigt haben. Ein über das Netzwerk bootfähiger Raspberry Pi ist eine Option für Rechenzentren, möglicherweise gibt es bald mehr Raspberry Pi Root Hoster.

Raspberry Pi über das Netzwerk booten

Mit der Netzwerk Boot Option (network booting) ist es nun erstmals möglich den Raspberry Pi komplett ohne SD Karte und anderen angeschlossenen Speichergeräten direkt über ein Betriebssystem Image aus dem Netzwerk zu starten. Das hat mehrere Vorteile, die vor allem Rechenzentren zugute kommen:

• keine Probleme mehr mit kaputten SD Karten
• NFS Images können für mehrere Raspberry Pis verwendet werden, nur die zentrale Quelle muss aktualisiert werden
• man kann Raspberry Pis komplett ohne angeschlossene Geräte betreiben (headless)

Das Setup für das folgende Tutorial sieht wie folgt aus:

• einen DHCP Server der für das Netzwerk das Image bereitstellt
• einen oder mehrere Clients

In meinem Fall sind das zwei Raspberry Pi 3 Geräte. Der erste übernimmt die Rolle des Servers und benötigt ganz normal eine SD Karte mit dem Raspbian Image, der zweite Raspberry Pi 3 wird ausschließlich über das Netzwerk gebootet und benötigt keinen Speicher. Das Tutorial basiert auf dem Artikel auf raspberrypi.org.

Client Konfiguration

Wie bereits im letzten Artikel erwähnt muss man am Raspberry Pi 3 im ersten Schritt die neuen Bootoptionen aktivieren. Das funktioniert mit einer speziellen start.elf und bootcode.bin Datei. In originalen Anleitung wird vorgeschlagen dazu Raspbian Lite auf eine SD Karte zu kopieren. Falls man das macht sollte man im ersten Schritt rpi-update und rsync nachinstallieren:

sudo apt-get update; sudo apt-get install rpi-update rsync
sudo BRANCH=next rpi-update

Im nächsten Schritt aktivieren wir die neuen Boot Optionen:

echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt

Das fügt den Konfigurationsparameter program_usb_boot_mode=1 ans Ende der config.txt im boot Ordner. Man muss den Raspberry Pi nun neu starten. Nach dem Neustart sollte

vcgencmd otp_dump | grep 17:

die Ausgabe 3020000a liefern. Damit stellen wir sicher, dass die neuen Bootmodi  verfügbar sind. Nun können wir die letzte Zeile in der config.txt wieder entfernen:

sudo nano /boot/config.txt

Wir können die Pi nun ausschalten, die Konfiguration ist vollständig.

Server Konfiguration

Nachdem wir beim Client die Option aus der config.txt wieder entfernt haben können wir die SD Karte vom Client entfernen und nun für den Server verwenden. Es wird vorgeschlagen nun das Filesystem auf die gesamte SD Karte auszudehnen. Das geht über das Raspberry Pi Konfigurationstool:

sudo raspi-config

Das ist zwar nicht zwingend notwendig, macht aber Sinn, wenn man den Server sinnvoll einsetzen möchte.

Netzwerk Dateisystem bereitstellen

Der Client bezieht beim Netzwerk Boot sein Dateisystem über das Netzwerk. Wir müssen deshalb auf dem Server dieses in irgend einer Art und Weise bereitstellen. Ob das nun auf der SD Karte oder einem angeschlossenen Massenspeicher liegt ist ganz egal. Im einfachsten Fall erstellt man nun auf der SD Karte ein 1:1 Abbild des Filesystems:

sudo mkdir -p /nfs/client1
sudo rsync -xa --progress --exclude /nfs / /nfs/client1

Wir erstellen einen neuen Ordner für das Filesystem unseres ersten Client Rechners und kopieren anschließend das komplette Dateisystem dort hinein. Der nfs Ordner selbst wird davon ausgenommen. Wie auch im letzten Tutorial müssen wir im Anschluss die SSH Schlüssel regenerieren:

cd /nfs/client1
sudo mount --bind /dev dev
sudo mount --bind /sys sys
sudo mount --bind /proc proc
sudo chroot .
rm /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
exit
sudo umount dev
sudo umount sys
sudo umount proc

Netzwerkinformationen bereitstellen

Im folgenden gehe ich davon aus, dass der Raspberry Pi 3 Server bereits im Netzwerk läuft. Ob LAN oder WLAN ist da egal. Mit dem folgenden Kommando finden wir heraus, welche IP das Gateway für dieses Netzwerk bereitstellt:

ip route | grep default | awk '{print $3}'
ip -4 addr show dev eth0 | grep inet

Das erzeugt eine Ausgabe wie diese:

inet 192.168.1.101/24 brd 192.168.1.255 scope global eth0

In diesem Fall hat der Server die IP Adresse 192.168.1.101, ist mit LAN verbunden (eth0) und die Broudcast Adresse für das Netz ist 192.168.1.255. Für jeden der ein wenig Ahnung von Netzwerktechnik kein Problem zu verstehen. Zusätzlich zu diesen beiden Informationen benötigen wir noch die IP Adresse vom DNS Server. Diese bekommen wir mit folgendem Kommando:

cat /etc/resolv.conf

Statische IP setzen

Ich habe bereits an anderer Stelle gezeigt wie man auf dem Raspberry Pi eine statische IP setzen kann. Das müssen wir nun auch bewerkstelligen. Die Konfiguration dafür findet man unter:

sudo nano /etc/network/Interfaces

Die Zeile

iface eth0 inet manual

muss nun mit folgender Konfiguration ersetzt werden:

auto eth0
iface eth0 inet static 
        address 192.168.1.2
        netmask 255.255.255.0
        gateway 192.168.1.1

Die neue Netzwerk Adresse des Servers wird 192.168.1.2, als Gateway wurde in diesem Fall 192.168.1.1 definiert, das ist mein WLAN Router. Nun schalten wir den DHCP Daemon aus und wechseln auf das normale Debian Networking:

sudo systemctl disable dhcpcd
sudo systemctl enable Networking

einmal mit sudo reboot neu starten und die Änderungen treten in kraft.

DHCP vorbereiten

echo "nameserver 192.168.1.1" | sudo tee /etc/resolv.conf

Im nächsten Schritt fügen wir das Gateway den DNS Einträgen hinzu. Mit dem nächsten Kommando machen wir die Datei unveränderbar, damit dnsmasq diese nicht mehr verändern kann:

sudo chattr +i /etc/resolv.conf

Laut der Dokumentation müssen wir an dieser Stelle noch einmal zusätzlich Software installieren:

sudo apt-get update
sudo apt-get install dnsmasq tcpdump

dnsmasq soll nun mit der DNS Namensauflösung aufhören aufhören:

sudo rm /etc/resolvconf/update.d/dnsmasq
sudo reboot

Nach dem Neustart starten wir tcpdump um nach DHCP Paketen vom Client Raspberry Pi zu suchen

sudo tcpdump -i eth0 port bootpc

Raspberry Pi Client kommt ins Spiel

An dieser Stelle stecken wir nun den Client Raspberry Pi den wir im ersten Teil des Tutorials konfiguriert hatten ans Netzwerk und starten ihn. Nach circa 10 Sekunden sollten wir das erste Paket vom Client Rechner über das Netzwerk am Server empfangen. Da werden auf der Kommandozeile Zeilen wie diese auftauchen:

IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from b8:27:eb...

Bis jetzt ist die Kommunikation sehr einseitig, denn der Server antwortet auf die Client anfragen nicht. Das ändern wir nun indem wir dnsmasq konfigurieren um auf DHCP Anfragen zu antworten:

sudo echo | sudo tee /etc/dnsmasq.conf
sudo nano /etc/dnsmasq.conf

Den gesamten Inhalt der Datei mit folgenden Text ersetzen:

port=0
dhcp-range=192.168.1.255,proxy
log-dhcp
enable-tftp
tftp-root=/tftpboot
pxe-service=0,"Raspberry Pi Boot"

Wie man sieht wird die IP Adresse des Broadcast des eigenen Netzwerk eingesetzt. Dieses müsst ihr gegebenenfalls an eure Netzwerkkonfiguration anpassen. In der Konfiguration wir ebenfalls auf einen Ordner /tftpboot verwiesen. Diesen erstellen wir nun wie folgt:

sudo mkdir /tftpboot
sudo chmod 777 /tftpboot
sudo systemctl enable dnsmasq.service
sudo systemctl restart dnsmasq.service

Ob alles läuft erfahren wir indem wir den dnsmasq log näher ansehen. Wir geben auf der Konsole jeweils die neu eintreffenden Zeilen aus:

tail -f /var/log/daemon.log

Man achte auf folgende Log Einträge:

raspberrypi dnsmasq-tftp[1903]: file /tftpboot/bootcode.bin not found

Es wird im neu angelegten Ordner nach der bootcode.bin Datei gesucht. Diese existiert nicht, wir legen sie deshalb zusammen mit der start.elf Datei an. Zusätzlich benötigen wir auch noch einen Kernel, am besten kopiert man das komplette boot Verzeichnis:

cp -r /boot/* /tftpboot

Der Client Raspberry Pi wird nun soweit booten können bis das Dateisystem ins Spiel kommt. Das fehlt noch und wird im letzten Schritt noch hinzugefügt.

NFS Dateisystem

Ganz zu Beginn haben wir unser Dateisystem geklont und im /nfs/client1 Ordner abgelegt. Das soll nun als root Dateisystem für den Client Rechner verwendet werden. Das geht mit folgenden Schritten:

sudo apt-get install nfs-kernel-server
echo "/nfs/client1 *(rw,sync,no_subtree_check,no_root_squash)" | sudo tee -a /etc/exports
sudo systemctl enable rpcbind
sudo systemctl restart rpcbind
sudo systemctl enable nfs-kernel-server
sudo systemctl restart nfs-kernel-server

So jetzt haben wir es gleich geschafft. Wir müssen nur noch die /tftpboot/cmdline.txt Datei konfigurieren. Die Zeile root= wird wie folgt geändert:

root=/dev/nfs nfsroot=192.168.1.2:/nfs/client1 rw ip=dhcp rootwait elevator=deadline

Wir setzen hier die IP Adresse vom Client Rechner. Ein letzter Schritt hindert uns noch, damit das System auf dem Client Rechner korrekt startet. Wir müssen die beiden Einträge der SD Karte aus der fstab löschen. Dazu öffnen wir die fstab Datei des kopierten Dateisystems:

sudo nano /nfs/client1/etc/fstab

und löschen beide Einträge /dev/mmcblkp1 und /dev/mmcblkp2.
Wow, fertig. Der Client Raspberry Pi startet jetzt ohne angeschlossenen Speicher über das Netzwerk und schreibt sein Dateisystem auf den am Server angelegten Ordner. Wir können nun die Konfiguration für einen zweiten, dritten, …usw. Client beginnen.

Raspberry Pi 1, 2 und Pi Zero

Für die älteren Modelle gibt es den Bootmodus auch, jedoch kann dieser nicht ohne SD Karte gespeichert werden. Wie schon im Artikel zum USB booten reicht es wenn eine modifizierte bootcode.bin Datei auf der SD Karte kopiert wird. Die erste Bootphase läuft dann von der SD Karte, der Rest kommt dann über das Netzwerk.

Fazit

Ich habe euch in einem sehr langen Artikel gezeigt wie man den Raspberry Pi über das Netzwerk booten kann. Diese Bootoption ist neu und derzeit noch in einem Beta Status. Trotzdem kann man es schon sehr gut einsetzen um mehrere Raspberry Pi Clients über das Netzwerk von einem zentralen Netzwerkspeicher (NAS) aus gestartet werden. Endlich braucht man sich keine Gedanken mehr zu defekten SD Karten machen und kann für die komplette Raspberry Pi Client Farm auf einmal ein Backup erstellen.

Was denkt ihr darüber? Wie viele Raspberry Pis laufen bei euch über das Netzwerk?