Am 21. April erscheint die nächste Ubuntu-Version Jammy Jellyfish mit LTS (Long Time Support), die 5 Jahre lang mit Updates versorgt werden wird. Üblicherweise aktualisiere ich unsere Rechner schon drei, vier Wochen vor dem finalen Release und so habe ich eben auch den Sprung von 21.10 auf 22.04 gewagt. Konkret ging es um fünf Installationen von Kubuntu auf auf unterschiedlichen Notebooks von Dell und Lenovo sowie einem Desktop-Rechner. Im Folgenden wird das ein oder andere Stolpersteinchen beschrieben, wobei es ja auch noch knapp einen Monat Zeit ist, bis das letztendliche Release erscheint.
Durchführung des Updates
Die Aktualisierung folgt dem normalen Prozedere: zunächst werden alle Aktualisierungen auf der vorherigen Version eingespielt. Anschließend kann der Update-Vorgang über das Kommando do-release-upgrade -d gestartet werden. Sollte dieses Kommando nicht verfügbar sein, muss gegebenenfalls noch das Paket update-manager-core nachinstalliert werden.
Im Wesentlichen laufen die Aktualisierungen weitgehend automatisch durch. Eine Besonderheit bei diesem Update betrifft die Umstellung des Firefox-Browsers auf eine Snap-basierte Version, was damit zusammenhängt, dass diese zukünftig direkt von Mozilla gepflegt wird. Sofern der Rechner per LAN mit dem Internet verbunden ist, kann diese Umstellung direkt vollzogen werden. Bei WLAN kann es vorkommen, dass die Konnektivität in dem Moment, in dem die Daten aus dem Snap Store geladen werden sollen, gerade nicht gegeben ist. In dem Fall fragt das System nach, wie damit umgegangen werden soll. Hier kann die Aktion Skip ausgewählt werden: die Installation der Snap-Variante erfolgt dann automatisch etwas später im Prozess.
Einmal Aufräumen bitte
Nach dem Einspielen aller Updates, dem Entfernen obsoleter Pakete und dem Neustart zum Ende des Prozesses sind in der Regel noch kleinere Aufgaben durchzuführen, um ein paar Altlasten zu entfernen.
Zum Beispiel können mit apt autoclean und apt clean verbliebene Paketdateien und Reste nicht mehr installierter Pakete gelöscht werden.
Ein Blick auf die Kernelversion (uname -a) zeigt, dass nun die Kernelreihe 5.15 verwendet wird. Die älteren Kernel 5.13 können daher entfernt werden: apt-get remove --purge linux-headers-5.13* linux-image-5.13* linux-modules-5.13* linux-modules-extra-5.13*.
In Kubuntu kommt nun übrigens die Plasma-Version 5.24.3 zum Einsatz. Diese hatten wir aber bereits unter 21.10 (Impish Indri) benutzt, da diese Version auch im Kubuntu Backports PPA liegt.
Apropos: zusätzliche Paket-Repositories werden beim Distributions-Update deaktiviert und müssen nun wieder angeschaltet werden. Am einfachsten werden hierzu die Dateien in /etc/apt/sources.list.d/ bearbeitet. Zu beachten ist, dass hier auch die Linie von impish auf jammy verändert werden sollte - sofern das jeweilige PPA diese bereits unterstützt (notfalls im Web nachschauen).
Werden anschließend die Pakete mit apt update neu geladen, kann es vorkommen, dass eine Meldung erscheint, weil einzelne GPG-Keys in einer als veraltet definierten Datei /etc/apt/trusted.gpg liegen. Das hat den Hintergrund, dass das Werkzeug apt-key bald nicht mehr gepflegt wird. Die Lösung ist ganz einfach: der jeweilige Key muss in einer einzelnen Datei in den Ordner /etc/apt/trusted.gpg.d/ abgelegt werden.
- Beispiel für Skype:
curl https://repo.skype.com/data/SKYPE-GPG-KEY | sudo tee /etc/apt/trusted.gpg.d/skype.asc - Beispiel für TeamViewer:
curl https://download.teamviewer.com/download/linux/signature/TeamViewer2017.asc | sudo tee /etc/apt/trusted.gpg.d/TeamViewer2017.asc
Update: die Verwendung von /etc/apt/trusted.gpg.d/gilt aus Sicherheitsgründen schon eine Weile als offiziell deprecated und sollte daher nicht mehr verwendet werden. Debian speichert Keys von Dritten stattdessen seit längerem unter /usr/share/keyrings/ ab, neuerdings wird wohl auch /etc/apt/keyrings/ verwendet; wobei das Verzeichnis im Prinzip egal ist, denn diese Keys werden im Gegensatz zu trusted.gpg nicht automatisch benutzt, sondern müssen bei der konfiguration des repos explizit angegeben werden:
deb [signed-by=/usr/share/keyrings/<key file>] <repo>
Besonderheiten bei einzelnen Applikation
Die einzige Anwendung, die bemerkbar Probleme macht, ist der - leider ohnehin etwas vernachlässigte - Linux-Client von MS Teams. Wie reddit und den Microsoft Q&A entnehmen lässt, scheint das Problem daher zu rühren, dass Teams eine zu alte Version von glibc verwendet. Bis ein entsprechendes Update zur Verfügung gestellt wird, bleiben alternativ entweder die Webversion in Google Chrome oder die Snap-Version des Clients. Ich habe letzteren ausprobiert und bin damit gegenwärtig ausreichend bedient.
Wie oben erwähnt wird auch Firefox mit dem Update auf Snap umgestellt. Dabei wird das bisherige Profil mitsamt aller Daten (AddOns, Lesezeichen, usw.) automatisch übernommen. Auf einem Rechner schien da irgendwas schief gelaufen zu sein, nach dem Start des Browsers präsentierte sich ein komplett neues Profil. Eine kurze Analyse zeigte, dass die früheren Daten aber korrekt aus ~/.mozilla/firefox/ nach ~/snap/firefox/common/.mozilla/firefox/ kopiert worden waren. Eine Änderung des Pfades zum gewünschten Profil in der dort befindlichen Datei profiles.ini schaffte Abhilfe.
Noch nicht gelöst ist indes die Integration des Browsers mit KeePassXC. Hierzu gibt es diverse Tickets (z. B. hier, hier, hier, hier, hier), die aber alle in Workarounds münden (eben keine Sandbox-basierte Version zu nutzen) und somit noch nicht eine wirkliche Lösung bringen. Es gibt Vorschläge für eine solche, aber da ist aktuell noch nichts verfügbar. Das dazugehörige Ticket für Ubuntu ist übrigens hier zu finden.