Debian 11 auf Rock64

vorhergehende Artikel in: Linux
21.07.2022

Nachdem bei mir ein rock64 freigeworden war und ich mir überlegt habe, was ich damit anfangen könnte kam die Idee eines Kubernetes-Trainingsclusters wieder einmal zum Vorschein - dazu wäre es aber gut, zunächst erst einmal eine aktuelle Basisinstallation zu haben...

Der Grund für das frei werden des Rock64 war das Anwachsen meines Docker-Zoos: die verschiedenen Container brauchten irgendwann mehr als das eine Gigabyte RAM, das ein Rock64 zu bieten hat. Ich entschloss mich daraufhin, den Nanopi Neo 3 mit immerhin 2 GigaByte RAM zum Arm-Dockerserver umzuwidmen.

Nachdem ich das getan und dort alle Docker-Container zum Laufen gebracht hatte (im Falle von ttrss ein sehr langwieriger und schmerzhafter Prozess), konnte ich mich mit dem Vorhaben befassen, den Rock64 neu aufzusetzen. Dazu musste ich zunächst erst einmal wieder ein passendes Image finden - das war nicht so einfach, da ich vorhatte, den Massenspeicher wieder über USB3 anzubinden und ich auch davon booten wollte - im Idealfall hätte ich so ein völlig von SD-Karten freies System.

Dazu muss man zunächst den SPI-EEPROM entsprechend flashen.

Ich merkte recht schnell, dass ich dazu leider kein stock-Armbian nehmen konnte, da ein Booten vondem am USB3-Anschluss verbundenen Gerät nicht möglich war. Mit demselben Gerät am USB2-Anschloss war aber Booten problemlos möglich. Nach längerer Herumprobiererei landete ich schließlich wieder beim eigens dafür geschaffenen Image, mit dem das Booten per USB3 auch problemlos gelang.

Dann hatte ich zunächst einen Rock64, der nach dem Booten erfreulicherweise weniger als 40 MegaByteRAM verbrauchte, also für Experimente zur Verfügung stand. Während dieser Experimente rauchte natürlich auch noch ein POE-Adapter und die USB3-SSD ab, die ich eigentlich fest eingeplant hatte. Also mussten die weiteren Tests doch wieder mit SD-Karten stattfinden - aber die Bootfähigkeit über USB3 hatte ich glücklicherweise ja bereits nachgewiesen.

Die Installation, die ich mit diesem Image erreicht hatte war aber grauenhaft outdated: die Basis war ein Debian 9, aktuell ist Debian 11. Da ich sowieso gerade am Experimentieren war, suchte ich im Internet nach Anleitungen zum Upgrade von Debian (da ich normalerweise mit Ubuntu arbeite,wollte ich lieber einmal mehr als zuwenig nachgelesen haben. Ich fand diese Anleitung zum Upgrade von Version 9 auf 10 und wandte sie an - mit dem Ergebnis, dass ich nach erfreulich kurzer Zeit und anschließendem Reboot eine funktionierende Debian 10-Installation auf dem Rock64 mein Eigen nennen konnte!

Dadurch unvorsichtig geworden, versuchte ich das gleiche mit einem Upgrade von 10 auf 11 - auch hier fand ich auf Anhieb eine Anleitung, die mich mit einem Rock64 mit Debian 11 belohnte. Auch nacheinem Reboot funktionierte das System stabil und benötigte nicht messbar mehr RAM.

In das anschließende Hochgefühl schlichen sich allerdings bald Zweifel ein, die immer nagender wurden: Das alles war gut gelaufen - zu gut: da musste noch irgendwo ein Haken verborgen sein, das spürte ich!

Meine Vorahnungen wurden bestätigt: am nächsten Tag begann ich weitere Experimente und musste dazu auch einige Pakete neu installieren - apt informiert dabei gerne mal darüber, dass man noch Pakete auf dem System hat, die nicht mehr benötigt werden. Ohne mir durchzulesen, welche Pakete genau für überflüssig gehalten wurden führte ich apt autoremove aus und das System war Schrott: Fast jeder Versuch, eine Anwendung zu starten wurde mit der Meldung undefined symbol: g_date_copy quittiert.

Nach einiger Zeit gab ich auf und spielte das Backup ein und schwor, mir zu merken, dass auf Rock64 fürderhin apt autoremove verboten ist.

Artikel, die hierher verlinken

Beschleunigung von scp trotz verhältnismäßig schwacher Hardware

19.01.2023

Im Zuge meiner neuerlichen Experimente mit dem von mir liebevoll so genannten Trump-Board wurde ich mir wieder eines schmerzlichen Defizits dieser (und ähnlicher) Hardware bewusst: der mangelnden Geschwindigkeit beim Kopieren großer Dateien über das Netzwerk.

Kubernetes und Rock64

29.07.2022

Ich habe bereits darüber berichtet, wie ich versucht habe, eine stabile OS-Basis für ein Rock64-Board zu schaffen, mit der es möglich sein sollte, von einem am USB3-Anschluss verbundenen Massenspeicher zu booten.

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.