PXE Boot für Rock64

vorhergehende Artikel in: Linux Raspi
19.12.2020

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.

Artikel, die hierher verlinken

Thin Client Experimente

02.03.2023

Ich bin wahrscheinlich wieder mal als Letzter auf einen Trend aufmerksam gemacht worden: Da heutzutage die Beschaffung fon Raspberry Pi Minicomputern immer schwieriger wird, ist mancher dazu übergegangen, ausgemusterte Thin Client Computer mit amd64 kompatiblen Prozessoren an ihrer Stelle einzusetzen.

Spezielle Telegraf-Anpassungen für Rock64

20.12.2020

Obwohl mein letztes Vorhaben mit dem Rock64 kläglich gescheitert ist habe ich ihn in mein Netzwerklabor eingebaut - und das bedeutet, dass die 2-Faktor-Authentifizierung aktiviert ist und das System mittels Telegraf Daten an die Influx-DB meldet und mit Grafana überwacht werden kann:

Alle Artikel rss Wochenübersicht Monatsübersicht Github Repositories Gitlab Repositories Mastodon Über mich home xmpp


Vor 5 Jahren hier im Blog

  • Mandelbrot-Sets mittels Shadern berechnen

    17.05.2019

    Nachdem ich in den letzten verregneten Tagen auf Youtube in den Videos von Numberphile versunken bin, hat mich eines davon angestachelt, mich selbst mit dem Mandelbrotset zu beschäftigen. Als ich dann noch Code fand, der behauptete, das auf einer Graphikkarte mittels Shadern berechnen zu können, war es um mich geschehen...

    Weiterlesen...

Neueste Artikel

  • Erste Vor-Version eines Gis-Plugin für die sQLshell

    Wie bereits in einem früheren Artikel erwähnt plane ich, demnächst ein Plugin für die sQLshell anzubieten, das eine Visualisierung von Daten mit räumlichem Bezug im Stil eines Geoinformationssystems erlaubt.

    Weiterlesen...
  • bad-certificates Version 2.1.0

    Das bereits vorgestellte Projekt zur automatisierten Erzeugung von Zertifikaten mit allen möglichen Fehlern hat eine Erweiterung erfahren und verfügt über ein Partnerprojekt - beide sind nunmehr in der Version 2.1.0 freigegeben

    Weiterlesen...
  • SQLite als Geodatenbank

    Wie bereits in einem früheren Artikel beschrieben treibe ich derzeit Anstrengungen voran, die sQLshell attraktiver für Nutzer zu machen, die mit Geodatenbanken arbeiten.

    Weiterlesen...

Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.

Wer daran teilhaben und eventuell sogar davon profitieren möchte, muß damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.

Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...

PS: Meine öffentlichen GitHub-Repositories findet man hier - meine öffentlichen GitLab-Repositories finden sich dagegen hier.