Schwere Fehler im Update-System von openSUSE Leap 15.3

Das openSUSE Projekt hat 2. Juni die aktuelle Version des stabilen Zweigs Leap 15.3 herausgebracht. Nun gibt es schwere Probleme mit dem Update-System, die im schlimmsten Fall zu einem unbenutzbaren System führen können.

Zur Information: Dieser Blogbeitrag ist nicht aktuell. Das Problem besteht nicht mehr.

Ich nutze openSUSE wirklich gerne und berichte dementsprechend sehr regelmäßig über die Entwicklungen, aber das ist jetzt eine Blamage, die an einen GAU grenzt. Im stabilen Zweig fällt nach dem Release auf, dass das Update-System quasi unbenutzbar ist.

Startet man die YaST Online Aktualisierung, gibt es für zahlreiche Patches Fehler, bei denen die Aktualisierungsverwaltung die Deinstallation Hunderter Pakete empfiehlt.

Fröhlich, wer da nicht genau liest oder gar die Einspielung von Aktualisierungen automatisiert hat.

Abhilfe schafft momentan der Gang auf Kommandozeile

# zypper up

Dadurch nutzt man ein anderes Tool und umgeht das Problem, weil die YaST Online Aktualisierung mit zypper patch arbeitet, was wohl die gegenwärtig fehlerbehaftete Komponente ist. Unklar ist, ob mit zypper up alle bestehenden Sicherheitsaktualisierungen eingespielt werden.

Die Ursache liegt wohl im “Closing the Gap” und der Einbindung der neuen Update-Repositorien. Das Problem ist bekannt und wird gerade diskutiert. Aufgetreten ist das Problem anscheinend so kurzfristig, weil die neuen Update-Repositorien erst rund um den Release-Termin eingebunden wurden.

Ich weiß, dass viele meine ständige Kritik an Linux oder einzelnen Distributionen nervig finden, aber so etwas darf einfach nicht passieren! Nicht bei einer Variante, die für stabilitätsorientierte Anwender und den Server-Einsatz empfohlen wird! Wenn man so kurz vor der Veröffentlichung was an den Repositorien ändert und das nicht testet, braucht man sich wirklich nicht wundern.

Ich halte openSUSE natürlich weiter die Treue und hoffe, sie beheben das Problem schnell. Als halbwegs erfahrener Anwender testet man eine neue Version ja erst mal ausgiebig, bevor man sie produktiv ausrollt. Das openSUSE-Projekt wird sich aber fragen lassen müssen, ob es sinnvoll war, mitten in einem Zyklus die Art und Weise, wie man die Distribution erstellt, zu ändern und damit nicht bis openSUSE Leap 16 zu warten.

Aktualisierung vom 10.06.2021

Das Problem besteht nach wie vor. Es gibt keine offizielle Kommunikation dazu seitens openSUSE, sondern nur Hinweise in Mailinglisten. Das ist ein Debakel sondergleichen – sowohl was das Problem als auch die Kommunikation betrifft – und sollte im Nachgang dringend evaluiert werden, wenn man die LTS-Ambitionen nicht gleich wieder beerdigen möchte.

Aktualisierung vom 10.06.2021

Die meisten Probleme wurden inzwischen behoben, vereinzelt gibt es noch Schwierigkeiten. Die Ursache ist mir immer noch nicht klar. Die vollständig ausbleibende Kommunikation dazu (abseits der Mailingliste mit ihrer sehr geringen Reichweite) finde ich enorm schwach vom openSUSE-Projekt.

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. Fällt einem nicht viel zu ein. Erlauben sich ja irgendwie alle – also wirklich alle, die irgendwie was mit Software machen – hin und wieder mal so richtig in Klo zu greifen beim Ausrollen einer Aktualisierung. In einer stabilen Version fein ohne (ausreichend) Tests in Produktiv zu übernehmen ist natürlich die Königsdisziplin des Verkackens.

    Die Schadenfreude hält dann auch so lange, bis man mal wieder selber betroffen ist … Software halt, kannste nichts machen 😛

    • Ach, in solchen Fällen ist Schadenfreude mal ganz hilfreich fürs eigene Ego: Wenn schon die Profis dermaßen daneben hauen, dann findet man die eigenen Fehler plötzlich gar nicht mehr sooooo schlimm 😉

  2. Sehe ich nicht kritisch. Fehler passieren. Außerdem ist es empfehlenswert mit Upgrades zu warten, bevor man wechselt. Ich glaube Ubuntu LTS macht es so das ein Upgrade nach einiger Zeit angeboten wird.

    • Wir reden hier nicht von einem Versionssprung Ubuntu 18.04 -> 20.04, sondern von einem Minorrelease innerhalb einer Hauptversion. Im SLE-Jargon heißt das Service Pack.

      • Ist ärgerlich, keine Frage. Aber Fehler können passieren und egal ob 1 oder 2 Jahre, lieber doch etwas warten und gut ist.

        • Der Fehler wäre durch anständiges Testen einfach vermeidbar gewesen. Solche Fehler dürfen in einem halbwegs Professionelen Projekt eben nicht passieren. Das Wort Gau trifft es eigentlich schon ganz gut. Man gewinnt so etwas den Eindruck als ob gar keine Qualitätsicherung bei dem Projekt vorhanden wäre und der Benutzer als Alpha Tester dient. Selbst mit Arch ist mir sowas noch nie passiert.
          Ich hoffe, dass aus dem Fehler für die Zukunft gelernt wird.

  3. So was ist der guten Suse schon öfters passiert. Wird zwar meist flott gefixt, ist aber tatsächlich nervig. Deswegen warte ich inzwischen mit meinen Upgrades immer ein paar Monate, bis die Kinderkrankheiten auskuriert sind. So wurde BTRFS meiner Meinung nach viel zu früh unter’s Volk gebracht. Aber vielleicht braucht es das zum Reifen…
    Vielen Dank an die mutigen Tester und Frühumsteiger!

  4. Hatte diese Update-Probleme auch. Mit Stand zum 11.06.2021 konnte Suse die meisten Problem fixen. Offen sind z. Zt. Updates für Openoffice. Ansonsten läuft diese Distro knackig und stabil.

  5. Wenn man unter KDE mit dem Applet aktualisiert wird einem nicht die Deinstallation vorgeschlagen, sondern das Update schlägt einfach Fehl. Genauer gesagt er bricht vollständig ab und installiert gar nichts. Schön ist das nicht, gerade wenn man damit wirbt das jetzt der stabile Enterprise Unterbau jetzt an Bord. In der Vergangenheit waren die Updates immer sehr zuverlässig und wurden auch intensiv mittels http://openqa.opensuse.org/ getestet.

  6. Vmware -workstation läuft zwar nach einer Neuinstallation problemlos. Nach einem Reboot aber findet die Sofftware /dev/vmmon nicht mehr. Der Grund ist folgender, dass die Gerätedatei die von VMware – workstation hier eingetragenen Änderungen nicht speichert und daher nach einem Neustart nicht verfügbar sind. Ein zusätzliche Sicherung von /dev -Gerätedatei extern und nach dem Neustart wieder zurückkopieren funktioniert auch nicht, obwohl auf der Sicherung alle Änderungen da sind, werden sie nicht übernommen.

  7. Bei einer VM bin ich auch auf das Problem gestoßen. Dachte mir nur “Ach Du dickes Ei” und habe abgebrochen. Auf einem Server würde ich, wie Du schriebst, auch erstmal mehrere Wochen vergehen lassen bevor ich mich da richtung Versionssprung bewege.

    Dennoch suboptimal. Vielleicht aber auch einfach nur der nötige Warnschuss…

    Gruß

Schreibe einen Kommentar zu Anonymous Antwort abbrechen

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