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.

Allerdings hatte ich bisher unterschlagen, was ich dann damit vorhatte: Ich wollte endlich versuchen, mich damit dem Thema Kubernetes zu nähern. Das stellte sich llerdings als unmöglich heraus - der Kernel war einfach zu alt und hat unter anderem keine CGroups unterstützt - ein Feature, das für Kubernetes aber dringend gebraucht wird.

Daher ging ich nochmals zurück auf start und versuchte mein Glück mit Armbian erneut - zunächst mit den bekannten Folgen: Booten von SD-Karte funktionierte, Booten von einem an USB3 angeschlossenen Massenspeicher hingegen nicht. Die genaue Fehlermeldung gab nir dieses Mal aber Stoff zum Nachdenken: Sie besagte nämlich, dass ein Massenspeicher bzw. eine Partition mit einer bestimmten UUID gesuicht und nicht gefunden wurde. Die genannte UUID war aber genau diejenige der Pertition, dei am USB3-Anschluss verbunden war. Das bedeutete, das System musste von diesem Datenträger gelesen haben - denn die UUID stand in den Konfigurationsdateien als Root-Partition. Lag es also doch am Kernel?

Ich recherchierte daraufhin ein wenig und stieß auf einige Meldungen über Probleme mit zu neuen Armbian-Versionen in Verbindung mit dem USB3-Anschluss auf Rock64-Bords. Es war zwar in all diesen Beiträgen nie exakt von meinem Problem die Rede - aber es reichte, um eine neue Serie von Experimenten zu planen. Ich lud also mehrere Armbian-Versionen mit verschiedenen 5.x Kerneln herunter und machte mich an die undankbare Aufgabe, sie zu testen. Die Hypothese stellte sch tatsächlich als wahr heraus: Irgendwo zwischen Armbian_20.05.1_Rock64_buster_current_5.4.43 uns Armbian_20.11.3_Rock64_buster_current_5.9.14 hat sich ein Bug eingeschlichen. Genauer habe ich es nicht mehr eingegrenzt, da Kubernetes auf dem Rock64 mit Kernel 5.4 funktioniert. Wichtig ist aber, dass man natürlich Kernel-Updates auch hier wieder verhindern muss - ein unbedachtes apt upgrade sorgt nämlich dafür, dass - ohne weitere Maßnahmen - der Kernel aktualisiert wird und damit das Booteen von USB3 wieder fehlschlägt.

Nun konnte ich mich ersten Experimenten mit Kubenetes widmen - ich habe unten einige Links zusammengestellt, die mir dabei halfen, das System in Betrieb zu nehmen und das Dashboard zu sehen. Ich weiß allerdings nicht, ob ich dieses Experiment in dieser Form weiter fortsetze: auf dem Master sind von den zur Verfügung stehenden 1024 GB RAM bereits 700 belegt ohne dass irgend etwas produktives geschieht...

Links