Ich hatte letztens ein Issue bei Eye of Gnome eröffnet, wo mir während der Diskussion gesagt wurde, dass ich einfach eine viel zu alte Version einsetze - mit der aktuellen könne das nicht nachvollzogen werden. Das startete eine wilde Reise - Ich verwendete nämlich noch die letzte LTS-Release von Ubuntu (22.04) und führte zunächst ein Upgrade auf 24.04 aus - oder zumindest wollte ich das...

&tldr; - Das Issue

Nachdem ich das Upgrade schlussendlich erfolgreich vollzogen hatte, stellte ich fest, dass ich den Fehler noch genau so sah - es lag also nicht an der zu alten Version. Dann bekam ich den Tip, es mit der Kommandozeilenanwendung der Bibliothek, die EoG zum Rendern von SVG benutzt zu versuchen - der Fehler tauchte tatsächlich nicht auf. Nach der Verlagerung des Tickets zu besagter Bibliothek Wurde diskutiert, ob es evtl. daran liegen könnte, dass ich immer noch X11 anstatt von Wayland benutzte - und das konnte ich bestätigen!

Allgemeines

Ich analysierte zunächst mein HomeLab und musste erschrocken feststellen, dass ich tatsächlich mehrere Ubuntus in verschiedensten Versionen vorfand: die älteste war 18.04! Damit entschied ich mich, alle vorgefundenen Installationen zu aktualisieren. Das betraf bare-metal Installationen von Servern und Desktops, LXC-Container und mehrere unprivileged LXC-Container.

Ganz generell lässt sich sagen, dass ich - obwohl ich das vorher nicht noch einmal explizit getestet hatte - mir sicher war, überall den NetworkManager durch ifupdown ersetzt und systemd.resolvd entfernt zu haben - nach dem Upgrade musste ich das alles erneut einrichten.

Einige Upgrades funktionierten nicht sofort wegen held back packages - aber das ließ sich zum Glück alles bereinigen.

Während der Upgrades - speziell bei bare-metal Sstemen mit separater, kleinerer root-Partition stieß ich auf die Tatsache, dass Ubuntu in der Standard-Konfiguration des Systemd 14 GB Log-Dateien zulässt. Zählt man das mit den zwei verwaisten Log-Dateien mit jeweils ungefähr 5 GB Umfang, die ich im Zuge der Untersuchung gefunden habe zusammen, so waren auf dem Desktop-System stattliche 25 GB der 60 GB umfassenden root-Partition von Systemd-Log-Dateien vollgeschmiert. Ich änderte die Konfiguration umgehend asuf dem Desktop und schrieb mir ein entsprechendes ToDo für die Server (bare-metal und LXC)!

Generell kann man sagen, dass Pötterings Monster (systemd) für fast alle der Zusatzarbeiten verantwortlich war, die nach dem Upgrade jeweils anfielen. Beim Desktop hatte ich tatsächlich die wenigsten Schwierigkeiten, hier - wie bei allen anderen Upgrades auf 23.10 oder 24.04 stellte sich lediglich ein interessantes Problem bei der Authentifizierung heraus: Ich setze zur Absicherung aller Linüxe beim Arbeiten mit Administratorrechten (sudo) 2-Faktor-Authentifizierung ein. Diese funktionierte nach dem Upgrade auf 23.10 nicht mehr - ich konnte mich plötzlich wieder nur mit dem Password authentifizieren. Eine kurze Analyse brachte zu Tage, dass als Teil des Upgrades eine neue Datei in /etc/pam-d/ installiert worden war - sie hieß sudo-i und wurde angewendet, wann immer ich das Kommando sudo -i eingab - früher wurde dazu die Konfiguration /etc/pam-d/sudo benutzt, weil es keine spezifischere gab. Ich änderte also in allen Linüxen, die ich erfolgreich auf mindestens 23.10 upgraden konnte die Datei /etc/pam-d/sudo-i entsprechend ab, um auch hier wieder die 2-Faktor-Authentifizierung zu aktivieren.

Eine Sache, die ich dringend korrigieren musste, war die Installation von Firefox und nun auch Thunderbird als Snap. Das wurde abgestellt - und wie ich hoffe, dauerhaft...

Ein weiterer interessanter Fakt war, dass ich auf keinem der untersuchten Systeme schaffte, direkt von 22.04 auf 24.04 zu upgraden: do-release-upgrade war der Meinung, dass kein neues LTS-Release zur Verfügung steht - daher musste ich immer über 23.10 gehen - ein Umweg, für den ich noch dankbar sein sollte - doch dazu später mehr...

bare-metal

Bei den Servern hatte ich mit dem Upgrade Erfolg - auch wenn zwei der drei Server zunächst vergessen hatten, dass sie über Netzwerkverbindungen verfügten. Das konnte ich - nachdem ich es erkannt hatte - schnell lösen. Natürlich geschieht das immer an Rechnern, die keinen Monitor und auch keine Tastature angeschlossen haben, so dass das Upgrade, das ja eigentlich eine reine Software-Maßnahme sein sollte zu teils deutlichen Umbauaktionen an der Büroeinrichtung führte...

LXC-Container

Die LXC-Container, die unter dem Nutzer root laufen wurden anschließend zunächst sicherheitskopiert und dann begann das Upgradevon

• pxebootserver,
• tvheadendserver,
• gitlab und
• docker

Diese Upgrades verliefen bis auf die unter Allgemeines gemachten Anmerkungen unkompliziert - jedoch habe ich es nicht geschafft, irgendeinen dieser Container über 23.10 hinaus zu upgraden - diese Forschungsarbeit nach der Ursache steht hier noch aus.

Ein sehr interessanter Punkt verdient hier noch Hervorhebung: Auf dem Gitlab-System funktionierte nach dem Upgrade meine CI/CD Pipeline nicht mehr - der Grund dafür war die Fehlermeldung ModuleNotFoundError: No module named 'anybadge' - und wie sich herausstellte, wurden diverse Python3-Module beim Upgrade tatsächlich entfernt. Warum das geschah, wird wohl auf ewig Ubuntus Geheimnis bleiben...

unprivileged LXC-Container

Die unprivileged Container starteten nach dem Upgrade des bare-metal-Servers, auf dem sie ausgeführt werden sollten, zunächst gar nicht mehr. Nachdem ich einige Tage erfolglos versucht hatte, sie wieder zur Mitarbeit zu bewegen (ich hatte natürlich vorher auch hier Backups angefertigt), machte ich mich bereits mit der Idee vertraut, die Geoinformationssysteme völlig neu aufzusetzen - es handelte sich nämlich um

• hillshading,
• osm und
• osmpostgresl

Dann hatte ich aber nochmal eine zündende Idee: Ich installierte ein Ubuntu 18.04 in einer KVM-VM und kopierte die Container dorthin. Nachdem ich die VM für unprivilegierte Container fitgemacht hatte (Installation von lxc-utils, ifupdown und Konfiguration von suid und Erlauben von Netzwerknutzung durch unprivilegierte Container), ließen sich die Container dort wieder starten. Ich begann meine Tests mit dem kleinsten (hillshading) und konnte zunächst auf 20.04 upgraden - auch dieser ließ sich in der VM starten. Diesen Stand packte ich nun wieder ein, transferierte ihn auf das eigentliche Zielsystem und startete den Container dort: Fehlschlag! Bereits beim Versuch, die 18.04-Variante zu starten kamen seltsame Fehlermeldungen, die wiederum auf Pöterings Monster als Ursache hinzudeuten schienen, dieses MAl waren die Fehler zwar andere, aber sie deuteten für jemanden wie mich, der einen abgrundtiefen Haß gegen systemd kultiviert wieder in diese Richtung. Allerdings waren da auch cgroups erwähnt. Daher recherchierte ich nochmals und es stellte sich heraus, dass irgendwann zwischen 18.04 und heute auf cgroups2 umgestellt wurde und im Zuge dessen unprivilegierte Container nicht mehr - wie früher üblich - mittels lxc-start gestartet werden dürfen, sondern mit lxc-unpriv-start. Damit konnte ich den Container auf dem Zielsystem starten und die weiteren Upgrades ganz normal dirt ausführen. Ich versuchte, das Originalsystem (18.04) mittels lxc-unpriv-start zu starten - das jedoch funktionierte nicht. Der Schritt über die VM war für das Upgrade tatsächlich unbedingt notwendig.

Bei dem Desktop-System, das ich als unprivilegierten LXC-Container betreibe, musste ich glücklicherweise diesen Umweg nicht gehen, da ich hier bereits ein Upgrade auf 20.04 durchgeführt hatte und daher alles Weitere wunschgemäß funktionierte.

Die beiden Container osm und osmpostgresql ließen sich leider nicht upgraden: Diverse essentielle Pakete waren gepinnt. Hier hilft dann wohl nur eine Neuinstallation.

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

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