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

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )