Ich wollte nach den Erfolgen, den ich mit dem Boot eines Raspberry Pi via PXE erzielt hatte auch das Rock64-Board auf diese Weise betreiben - Dieser Artikel erzählt die Geschichte meines Scheiterns...

Ich hatte ja bereits darüber berichtet, dass das Aufsetzen des Boot über Netzwerk für meinen Raspberry 3B+ hervorragend funktionierte - ich habe die Root- und die Boot-Partition über NFS-Exports zur Verfügung gestellt und - das ist immer die Nagelprobe bei solchen Experimenten bei mir - bereits ein Systemupdate einschließlich Neubas der initrd erfolgreich über die Bühne gebracht.

Durch diese Erfolge unvorsichtig geworden startete ich den Versuch, mit meinem nagelneuen Rock64-Board ähnliches zu erreichen.

Dazu zuerst noch einmal ein rascher Überblick über die bisherige Situation: DHCP-Server ist in meinem Heimnetz-Labor immer noch die Fritz-Box. DNS-Server und NTP-Server wird von einem Raspberry 3 zur Verfügung gestellt, der sich auch um Monitoring mittels Influx und Grafana kümmert. Die DNS-Server-Adresse wird durch die Fritzbox an alle Clients verteilt. Das Booten über PXE habe ich so eingerichtet, dass der Server dafür in einem LXC-Container virtualisiert läuft. Dieser PXE-Server stellt vier Services zur Verfügung, bon denen momentan drei aktiv genutzt werden: DNSMasq, NFS, SFTP (und HTTP). DSMasq läuft als Proxy - bietet also keinen eigenen DHCP-Dienst an, sondern sendet lediglich die Informationen über TFTP-Server und Bootfile-Name "huckepack" wenn er entsprechende Pakete zwischen Clients und Fritzbox sieht.

Dieses Setup wollte ich nachnutzen und versetzte den Rock64 dafür zunächst in die Lage, PXE- bzw. Bootp-Kommunikation durchführen zu können. Dazu spielte ich ein passendes Image in den auf dem Board befindlichen SPI-Flash-Baustein ein. Anschließend konnte ich im Wireshark tatsächlich ohne SD-Karte oder anderen Massenspeicher mit dem Board verbunden zu haben DHCP-Requests vom Board sehen. Leider blieb es dabei - DNSMasq antwortete nicht und so erhielt das Board keine Informationen zum weiteren Vorgehen. Nach längerer Analyse was der Unterschied zwischen Raspi und Rock64 sein könnte bemerkte ich, dass Raspi bereits beim Request die beiden PXE-Optionen TFTP-Server und Bootfile-Name mitsendet - der Rock64 tat das nicht. Für mich bedeutete das, dass es wahrscheinlich daran läge, dass DNSMasq sich als nicht zuständig wähnte.

Also erweiterte ich mein Netzwerklabor um ein eigenständiges Netzwerk, in dem ich einen vollständigen DHCP-Server (wieder DNSMasq) so konfigurierte, dass er ungefragt auf jede DHCP-Request-Anfrage TFTP-Server und Bootfile-Name in die Antwort packte. Als TFTP-Server ließ ich weiter den bestehenden PXE-Server arbeiten, der sich jetzt aber von den Clients aus gesehen in einem anderen Netzwerksegment befand. Dadurch musste ich noch dafür sorgen, dass Requests aus dem neuen Segment in das alte und ins Internet funktionierten. Das prüfte ich mittels HTTP(S), SSH und Ping. Nachdem das Setup soweit abgeschlossen war, bootete ich den Rock64 in dem neuen Netzwerksegment - im Wireshark war die Antwort vollständig zu sehen und das war die Einleitung des nächsten Fehlschlags: Die Kommunikation mittels TFTP wollte zwischen den Netzsegmenten nicht funktionieren. Ich habe ziemlich rasch aufgegeben, hinter den Grund für dieses Problem kommen zu wollen und variierte mein Setup nochmals: Ich setzte einen TFTP-Server in dem neuen Netzsegment auf. Das führte dazu, dass der Rock64 die Dateien (Kernel und initrd) vom TFTP-Server holte und bootete.

Allerdings tat sich auch sofort das nächste Problem auf: er konnte keine Verbindung zum NFS-Share aufbauen: Der NFS-Server meldete zwar, dass ein Client sich mit dem entsprechenden Share verbinden wollte aber einige Sekunden danach begann der Rock64 auf der Console zu melden, dass die Verbindung mit dem NFS-Share fehlgeschlagen sei. Mein letzter Versuch war, auf dem NFS-Server die Version 2 des Protokolls zu aktivieren - vielleicht konnte das zu einem Erfolg führen. Auch diese - zugegebenermaßen bereits recht verzweifelte - Aktion brachte keinen Erfolg: Das Verhalten änderte sich nicht. An diesem Punkt gab ich das Experiment als gescheitert auf - irgendeinen Grund musste es schließlich für den unverschämt günstigen Preis des Boards geben.

Ich benutze das Board immer noch gern als Host für verschiedene Docker-Dienste, die nicht übermäßig anspruchsvoll sind, was die Ressourcen angeht. Derzeit sind ungefähr 10 Docker-Compose-Stacks mit nicht ganz der dopüpelten Anzahl von Services darauf aktiviert. Das Gesamtsystem funktioniert stabil und es ist noch Platz für weitere Dienste: Der Ram des Systems ist derzeit zur Hälfte verbraucht.

Links

Artikel, die hierher verlinken