Canonical hat als neue Vision, als hätten „Mir“ und „Unity“ nicht gereicht, Pakete im Snap Format auszuliefern. (Siehe auch https://snapcraft.io/ ) Dabei handelt es sich um containerisierte Anwendungen – seit Docker in aller Munde ist, möchte man da natürlich nicht zurückstehen.

Und so kam es, dass mir bei meinem Notebook bei der Installation von Ubuntu 18.10 direkt auch Snap untergeschoben wurde. So richtig deutlich merkt man das nicht – wenn alles täte, wäre das ja auch ok.

Bis ich für den ODROID-N2 eMMC Karten über einen MicroSD Adapter beschreiben wollte. Als braver „DevOps“ automatisiert man alles. Kleines Shellscript, das per fdisk alles partitioniert, mit mkfs.vat/mkfs.ext4 die Dateisysteme erzeugt, Arch Linux herunterlädt und passend auspackt und dann noch schnell ein paar Settings vornimmt. Hatte sich bei dem ODROID-C2 Kubernetes Cluster, den ich gefühlte 20 Mal neu aufgesetzt hatte sehr bewährt.

Doch nun das Fiasko: Es tat nicht. Ganz merkwürdig nicht. Die Partitionen wurden korrekt angelegt, aber das Dateisystem hatte eine viel zu geringe Größe. Auch ging die Einrichtung gefühlt einen Hauch zu schnell. Das Auspacken von der Arch Linux Distribution tut dann natürlich nicht.

Ok, nimmt man gparted meldet es auch, dass das Filesystem zu klein sei, ob man das nicht reparieren wolle – klaro. Ein paar Animationen später soll alles ok sein, ist es aber nicht.

Durch Zufall fällt mir auf, dass „df“ andere Mountpoints meldet, als „mount“. Bei „mount“ ist es /dev/sda1, bei „df“ ist es /dev/loop29 …. die anderen Loop-Devices werden für Snap Pakete verwendet. Und da machte es nach ca. 7 Stunden intensiver Diagnose und „Ist-das-kaputt-oder-ich-verrückt“ Momenten endlich „klick“. Scheinbar werden elementare Werkzeuge in Snap-Containern ausgeführt – und das führt dann zu Effekten, wenn die Devices nicht korrekt durchgemappt sind. WTF.

Das Snap Zeug ist jetzt deinstalliert. Alle Probleme verschwunden – und der Weg damit frei zum Kubernetes Cluster auf ODROID-N2 Basis!