Kommentar: Die Tücken von Rolling-Release-Distributionen

Wenn ich über Rolling-Release-Distributionen und den Wartungsaufwand von Linux schreibe, kommen zuverlässig Kommentare, dass das alles kein Problem sei und man selbst seit x Jahren mit der Distribution y ohne Neuinstallation arbeitet. Kann sein. Muss es nicht. Vor allem aber fehlt es an Planbarkeit.

Ende Februar hat KDE das lange angekündigte Mega Release veröffentlicht. Dabei handelt es sich um die gleichzeitige Aktualisierung des Plasma-Desktops auf Version 6 und der nun auf Qt 6 basierenden Applikationssammlung. Im Gegensatz zu früheren Versionssprüngen ist KDE hier ein grundsolides Release gelungen. Es gibt sinnvolle Verbesserungen, keine großen Brüche, keine signifikanten Funktionseinbußen und vor allem keine riesigen Buglisten. Hier hat KDE definitiv dazugelernt.

Für ein paar Tage war dann Ruhe. Schließlich mussten die Entwickler erst testen, dann bauen und die QA musste auch noch drüber laufen. Aber letzte Woche wurde Plasma 6 und alles was dazu gehört in openSUSE Tumbleweed verteilt. Das geschah ohne Zeitplan und ohne große Ankündigung. Wem das gerade nicht in den Kram passte, weil er das System gerade dringend für einen Arbeitsprozess oder ähnliches benötigte, der konnte ab diesem Tag nur noch das Aktualisieren und Neuinstallieren von Paketen einstellen. Sicherheitsupdates kommen dann natürlich auch nicht mehr. Rolling Release heißt eben auch unweigerlich mitrollen.

Das Update selbst ruckelte sehr stark. Das berichten viele Nutzer. Die Probleme – das möchte ich ausdrücklich betonen – lagen nicht bei KDE, sondern bei der Update-Routine von openSUSE. Der eigentliche Vorgang über zypper brach bei Anwendern mit laufender Wayland-Session mittendrin ab. Wer dann nicht auf TTY wechselte und dort das Update beendete, hatte ein inkonsistentes System und landete bestenfalls nach einem Neustart wieder bei Plasma 5. Größere Probleme waren dann noch fehlende Übergänge bei SDDM, weshalb hier entweder die Konfigurationsmöglichkeit verloren ging oder gleich alle Pakete. Die automatische Entsperrung von KWallet über PAM funktionierte nicht mehr und die Desktopsuche Baloo hing in einem Mix aus 5 und 6 fest. Hinzu kamen kleinere und größere Probleme mit einzelnen Programmen. Je nach Einschätzung des Aufwandes konnte man sich dann entweder einzeln auf Fehlersuche begeben (wobei ein Unfallauto immer ein Unfallauto bleibt) oder neu installieren. Das Zurückspringen über Snapper und ein erneuter Versuch brachte letztlich meist ein ähnliches Ergebnis, ist also nicht die Lösung.

Jetzt wird natürlich wieder jemand schreiben, mit der Distribution xyz wäre das nicht passiert, man hätte nur dies und jenes beachten müssen usw. usf.

Aber meiner Ansicht nach zeigt diese fehlerhaften Aktualisierung wieder verschiedene Punkte:

  • RR-Verteilungen sind nur für den unkritischen privaten Gebrauch geeignet. Solche Großupdates sind nicht planbar, nicht vorhersehbar und nicht verschiebbar. Das macht RR-Distributionen für den produktiven Einsatz ungeeignet.
  • Die klassische Paketverwaltung mit ihren systemimmanenten Problemen ist am Ende ihres Entwicklungszyklus angelangt. Bessere Übergänge bei openSUSE hätten manches verhindert, aber das System aus tausenden Paketen mit fein definierten Abhängigkeiten und Überleitungen ist ein fehleranfälliges Konstrukt. Ein festes Image aus Basissystem und Desktop plus Anwendungsprogrammen hätte diese Probleme beim Update nicht verursacht.
  • Linux ist und bleibt wartungsintensiver als vergleichbare Systeme.
Cruiz
Cruizhttps://curius.de
Moin, meine Name ist Gerrit und ich betreibe diesen Blog seit 2014. Der Schutz der digitalen Identität, die einen immer größeren Raum unseres Ichs einnimmt ist mir ein Herzensanliegen, das ich versuche tagtäglich im Spannungsfeld digitaler Teilhabe und Sicherheit umzusetzen. Die Tipps, Anleitungen, Kommentare und Gedanken hier entspringen den alltäglichen Erfahrungen.
  1. Produktive Systeme würde ich immer so updaten, dass ich ein Rollback oder besser ein gespiegeltes System habe, auf das ich im Notfall ausweichen kann. Ich selbst verwende letzteres auf meinen privaten und berufliche Rolling Release-Systemen.
    Ein klassisches Windows oder Linux-Update ist auch immer ein Risiko für jeden produktiven Einsatz und es müssen Backuplösungen vorhanden sein, bzw. die Updates für den spezifisch geplanten Einsatz sehr gut getestet werden bevor sie ausgerollt werden. Ich sehe hier eher ein grundsätzliches Problem der Softwareaktualisierung als ein spezifisches Problem von Rolling Release-Distributionen.
    Nicht umsonst benutzten die US-Atomstreitkräfte immer noch Disketten ;-).

    • Und was mache ich dann? Ein erneuter Durchlauf endet ja wieder mit dem gleichen Resultat und längere Zeit nicht aktualisieren kann man sich wegen offener Sicherheitslücken nicht erlauben.

      • Und was mache ich, wenn ich Ubuntu 22.04 auf 24.04 upgraden will und (wie gewöhnlich) mehrere Programme oder Dienste nicht wie bisher laufen? Das muss dann auch zeitnah gelöst werden.

          • Also ausgerechnet [xlk]Ubuntu ist hier wirklich ein schlechtes Beispiel. Da gibt’s ja nun weiß Gott kaum Support für die alten Releases, trotz LTS, die wollen halt ihr Pro verkaufen. Und ein Migrationsupdate funktioniert i.d.R. auch eher nicht durchgängig. Nach 12 Jahren intensiver Nutzung wird’s bei mir aus genau diesem Grund kein Upgrade von 22.04 auf 24.04 mehr geben. Planbarer ja, aber eine Neuinstallation wirds dann trotzdem.

  2. Ja, RR-Distributionen würde auch ich nur privat verwenden, eine solche spontane Versionsänderung kann kein Admin “seinen” Anwendern zumuten. Anwender sind was das betrifft konservativ und wollen mehrheitlich keine Änderungen an der Software.

    Aber dass klassische paketbasierte Distributionen an ihrem Ende sind sehe ich überhaupt nicht so auch wenn ich sofort glaube dass ein Desktopupdate im laufenden Betrieb zu einigen Fehlern führen kann, es ist einfach nicht möglich hier alle Varianten im Vorfeld zu testen. Ich glaube dieser “Docker”-Ansatz mit festem Basisimage scheint nur auf dem ersten Blick sinnvoll und führt zu Problemen die man aktuell nicht sieht weil so nicht gemacht wird.

    • Subjektiv ist er deutlich geringer. Es fallen halt einige Fehlerquellen im Bereich der Pakettransitionen weg. Allerdings ist die Auswahl momentan halt noch sehr klein. Fedora Atomic Desktop ist da ziemlich alleine auf weiter Flur. OpenSUSE MicroOS ist noch nicht ausgereift, deshalb bin ich (vorerst) auch zu Tumbleweed zurück.

      • Also ich habe alles erlebt was Du geschildert hast. Und ja, wenn das so unkontrolliert passiert ist das schei…. Vor allem der erste Einschlag war heftig, inkl. zerschossenen snapshots. Trotzdem konnte ich zwei Anläufe immer wieder durch das Zurückspringen auf funktionierende snapshot beenden und etwas Zeit verstreiche lassen. Klar, auf dist-upgrade musste ich in der Zeit verzichten, stimmt.

        Erst der dritte Anlauf so kurz vor 6.0.2 verlief dann eigentlich so, wie man es sich schon beim ersten Versuch gewünscht hätte. Plasma aktuell und nach zwei/drei Einstellungen ist eigentlich alles wie vorher, was ich als sehr gelungen empfinde.

        Snapper hat bei mir also sehr gut funktioniert. Im Vergleich zu anderen RRs bin ich mit Tumbleweed bisher am allerbesten gefahren, deshalb hake ich diesen Ritt mit Plasma einfach ab.

        Möglicherweise ist slowroll eine Option, die in so einem Fall möglicherweise kontrollierter funktioniert. Hier also das Plasma Upgrade etwas zurückhält, während die sonst nötigen Paketupdates mit dist-upgrade weiterhin bereitgestellt werden. So zumindest meine naive Vorstellung 🙂

        Ich wünsche allen eine schöne Osternzeit.

Kommentieren Sie den Artikel

Ergänzungen dienen der Diskussion über die Inhalte des Artikels. Nachfragen, Anmerkungen und Ergänzungen sind dezidiert erwünscht. Ergänzungen werden vor der Veröffentlichung moderiert. Wir behalten uns vor Kommentare ohne inhaltlichen Bezug oder abseitige Diskussionen nicht zu veröffentlichen.

Bitte geben Sie Ihren Kommentar ein!
Bitte geben Sie hier Ihren Namen ein

Weitere Artikel