Ein Systemupdate sollte eigentlich eine langweilige Angelegenheit sein.

Nicht aufregend.

Nicht dramatisch.

Nicht „ich hoffe, mein Rechner startet danach noch“.

Man klickt auf „Aktualisieren“, wartet ein bisschen, startet neu und macht anschließend weiter, als wäre nichts gewesen.

Das ist zumindest die Theorie.

Die Praxis sah mit dem Ubuntu-Kernel 7.0.0-28.28 für manche Nutzer etwas anders aus.

Da standen plötzlich Begriffe im Raum, die man bei einem normalen Update nicht unbedingt sehen möchte:

Performance-Regression.

AMDGPU.

ROCm.

Kernel Panic.

GRUB-Menü.

Alter Kernel.

Bitte bleiben Sie ruhig, Ihr Rechner ist wahrscheinlich nicht dauerhaft beleidigt.

Und genau an diesem Punkt wird es unangenehm.

Denn wenn ein Ubuntu-Kernel Probleme macht, trifft das nicht nur Ubuntu selbst. Es trifft auch die ganzen Distributionen, die auf Ubuntu aufbauen und für viele Menschen überhaupt erst den freundlichen Einstieg in Linux darstellen.

Linux Mint.

Zorin OS.

elementary OS.

Pop!_OS.

TUXEDO OS.

Und andere Projekte, die Ubuntu als Fundament nutzen.

Diese Projekte haben den Kernel nicht geschrieben.

Sie haben den AMDGPU-Treiber nicht gebaut.

Sie haben nicht im Canonical-Büro gesessen und gesagt:

„Wisst ihr was? Heute machen wir Updates mal etwas würziger.“

Trotzdem bekommen sie am Ende oft den Ärger ab.

Denn der normale Nutzer sieht keine Paketgrenzen.

Der normale Nutzer sieht sein Distributionslogo.

Und wenn der Rechner nach einem Update nicht mehr sauber startet, denkt kaum jemand:

„Vermutlich handelt es sich um eine Regression im Ubuntu-HWE-Kernel oder um eine ungünstige Interaktion zwischen Kernel, DKMS-Modulen, Bootloader und initramfs.“

Nein.

Der normale Nutzer denkt:

„Mint ist kaputt.“

Oder:

„Zorin startet nicht mehr.“

Oder direkt:

„Linux ist Mist.“

Und genau das ist das Problem.

Der Kernel kommt aus dem Maschinenraum

Viele beliebte Linux-Distributionen bauen auf Ubuntu auf.

Das ist auch völlig verständlich.

Ubuntu bringt eine riesige Paketbasis mit, langfristige Unterstützung, Sicherheitsupdates, Hardware-Support, Kernelpflege und ein Ökosystem, auf dem kleinere Teams überhaupt erst sinnvoll aufbauen können.

Nicht jede Distribution kann ihren kompletten Unterbau selbst pflegen.

Nicht jedes Projekt hat ein Kernel-Team, eine Sicherheitsabteilung, eine Armada an Testsystemen und jemanden, der morgens liebevoll die DKMS-Module streichelt.

Kleinere Projekte setzen deshalb auf Ubuntu und bauen darauf ihre eigene Idee von Linux.

Linux Mint macht daraus einen vertrauten, ruhigen Desktop.

Zorin OS richtet sich stark an Umsteiger von Windows und macOS.

elementary OS versucht, ein geschlossenes, hübsches Desktop-Erlebnis zu bieten.

Pop!_OS legt Wert auf Hardwarefreundlichkeit und Produktivität.

TUXEDO OS ist eng mit konkreter Linux-Hardware verbunden.

Das alles funktioniert, solange der Unterbau stabil ist.

Aber wenn Canonical einen problematischen Kernel ausliefert, wandert das Problem wie ein schlecht gelaunter Paketkobold die Abhängigkeitskette hinunter.

Oben fällt ein Kernel vom Regal.

Unten sitzt irgendein Mint- oder Zorin-Nutzer und fragt sich, warum sein Rechner plötzlich so tut, als hätte er nie einen Desktop gekannt.

Der konkrete Fall: Kernel 7.0.0-28.28

Beim Ubuntu-Kernel 7.0.0-28.28 bestätigte das Ubuntu-Kernel-Team eine Performance-Regression im AMDGPU-Treiber.

Betroffen waren vor allem rechenintensive ROCm-Workloads, zum Beispiel Stable-Diffusion-XL-Inferenz über ComfyUI. In einem dokumentierten Beispiel stieg die Verarbeitungszeit von 9 Sekunden auf 388 Sekunden.

Das ist kein kleiner Schluckauf.

Das ist ungefähr so, als würde man einen Kaffee bestellen und die Maschine sagt:

„Gerne. Lieferzeit: Donnerstag.“

Canonical beziehungsweise das Ubuntu-Kernel-Team erklärte, dass die Regression bekannt sei und die Lösung bereits identifiziert wurde. Trotzdem sollte der Kernel zunächst erscheinen, weil wichtige Sicherheitskorrekturen enthalten waren. Betroffenen Nutzern wurde empfohlen, vorerst beim bisherigen Kernel zu bleiben, bis ein korrigiertes Update nachgereicht wird.

Technisch kann man diese Entscheidung nachvollziehen.

Sicherheitsupdates sind wichtig.

Kritische Lücken will man nicht unnötig offenlassen.

Ein Kernel ist kein kleines Icon-Theme, das man mal eben verschiebt.

Aber aus Nutzersicht bleibt ein sehr ungünstiger Eindruck:

Das normale Update bringt einen Kernel mit bekannter Regression.

Und damit sind wir bei dem Punkt, an dem Technik und Vertrauen gegeneinander laufen.

Nicht jedes Problem ist automatisch Canonicals Schuld

Jetzt muss man fair bleiben.

Nicht jedes Problem, das nach einem Kernelupdate auftritt, ist automatisch direkt der Kernel selbst.

Linux ist an dieser Stelle leider kein sauber sortiertes Bücherregal, sondern eher ein Technik-Keller, in dem jemand über Jahre hinweg Kabel, Treiber, Bootloader, DKMS-Module, Firmware und Hoffnungen übereinandergelegt hat.

Bei einem Kernelwechsel können verschiedene Dinge schiefgehen:

  • der Kernel selbst kann eine Regression enthalten,
  • ein DKMS-Modul kann nicht mehr bauen,
  • ein Grafiktreiber kann stolpern,
  • das initramfs kann fehlschlagen,
  • GRUB kann eine ungünstige Konfiguration erwischen,
  • VirtualBox, NVIDIA, Realtek oder andere externe Komponenten können beleidigt sein,
  • oder alles zusammen entscheidet, heute einen Betriebsausflug in den Fehlerzustand zu machen.

Für den Nutzer sieht das aber oft gleich aus:

Update installiert.

Neustart gemacht.

System kaputt.

Ob dahinter ein Kernel-Bug, ein DKMS-Problem, ein initramfs-Fehler oder ein Bootloader-Drama steckt, ist für viele erstmal zweitrangig.

Der Rechner startet nicht.

Das reicht als emotionale Diagnose völlig aus.

Die kleinen Distributionen sitzen am Ende der Support-Kette

Wenn Ubuntu selbst ein Problem bekommt, hat Canonical wenigstens die entsprechende Größe, Infrastruktur und Sichtbarkeit.

Aber Ubuntu-Ableger sitzen oft in einer deutlich unangenehmeren Position.

Sie übernehmen den Unterbau, bauen darauf ein einsteigerfreundliches System und müssen anschließend erklären, warum ein Problem im Keller nicht automatisch die Schuld der Tapete ist.

Zorin OS ist hier ein gutes Beispiel: Nach Problemen rund um das Kernel-7.0-Update schrieb das Zorin-Team im Forum, man habe entsprechende Probleme untersucht, Fixes in den eigenen Repositories bereitgestellt und betroffenen Nutzern erklärt, wie sie über die erweiterten Bootoptionen wieder den vorherigen Kernel starten können.

Und genau das ist die unsichtbare Arbeit.

Ein Kernelupdate geht schief.

Dann beginnt für kleinere Teams und Communitys die Nachtschicht:

Fehlerberichte lesen.

Muster erkennen.

Nutzer beruhigen.

GRUB erklären.

Alten Kernel auswählen lassen.

Terminalbefehle formulieren.

Fixes testen.

Foren moderieren.

Und zum zwanzigsten Mal erklären, dass der Laptop wahrscheinlich nicht dauerhaft tot ist.

Das ist Supportarbeit, die kaum jemand sieht.

Aber sie entscheidet darüber, ob ein Einsteiger nach so einem Vorfall denkt:

„Okay, das war unangenehm, aber mir wurde geholfen.“

Oder:

„Linux fasse ich nie wieder an.“

Der Nutzer sieht keine Paketgrenzen

Für erfahrene Linux-Nutzer ist die Sache halbwegs einordenbar.

Man kann unterscheiden zwischen:

  • Linux-Kernel,
  • Ubuntu-Kernelpaket,
  • HWE-Stack,
  • DKMS,
  • initramfs,
  • GRUB,
  • Distribution,
  • Desktopumgebung,
  • Treibern,
  • Firmware,
  • und dem, was irgendein Aufräumtool gestern als „nicht mehr benötigt“ bezeichnet hat.

Einsteiger sehen das nicht.

Und ehrlich gesagt: Sie sollten es auch nicht sehen müssen.

Wer Linux Mint installiert, nutzt Linux Mint.

Wer Zorin OS installiert, nutzt Zorin OS.

Wer elementary OS installiert, nutzt elementary OS.

Natürlich steckt darunter viel mehr. Aber einsteigerfreundliche Distributionen leben gerade davon, dass sie diese Komplexität abfedern.

Wenn nach einem Update der Bildschirm schwarz bleibt oder eine Kernel Panic erscheint, denkt niemand zuerst an Organisationsstrukturen innerhalb der Linux-Welt.

Man denkt:

„Meine Distribution hat meinen Rechner kaputtgemacht.“

Das ist menschlich verständlich.

Aber es ist bitter für die Projekte, die gar nicht die Hauptquelle des Problems waren.

Canonical liefert den Stolperstein.

Die kleineren Distributionen erklären anschließend, warum man darüber gefallen ist.

Ein zweiter Kernel ist keine Unordnung, sondern Rettungsleine

Dieser Vorfall zeigt außerdem wieder eine der wichtigsten Linux-Regeln:

Entferne niemals vorschnell den letzten funktionierenden Kernel.

Mehrere installierte Kernel wirken auf den ersten Blick wie digitaler Gerümpelkeller.

Da liegt dann der neue Kernel.

Der alte Kernel.

Vielleicht noch einer von letzter Woche.

Und irgendein Aufräumprogramm steht daneben und flüstert:

„Willst du das wirklich alles behalten?“

Ja.

Willst du.

Zumindest einen funktionierenden älteren Kernel.

Denn genau das ist deine Rettungsleine.

Wenn der neue Kernel nicht startet oder Probleme macht, kannst du im GRUB-Menü unter den erweiterten Optionen den vorherigen Kernel auswählen und wieder ins System kommen.

Das ist nicht elegant.

Das ist nicht schön.

Das ist nicht das Desktop-Erlebnis, mit dem man Windows-Umsteiger auf einer Hochglanz-Webseite anlächelt.

Aber es ist unglaublich wichtig.

Ein zweiter Kernel ist wie ein Ersatzschlüssel.

Man hofft, ihn nie zu brauchen.

Aber wenn man ihn braucht, möchte man nicht feststellen, dass man ihn gestern „zur Speicherplatzoptimierung“ weggeworfen hat.

Können Ubuntu-Ableger das nicht verhindern?

Teilweise.

Aber nicht vollständig.

Natürlich tragen auch Ubuntu-basierte Distributionen Verantwortung für das Gesamtsystem, das sie ihren Nutzern anbieten.

Sie können Updates verzögern.

Sie können Warnungen anzeigen.

Sie können eigene Tests durchführen.

Sie können bestimmte Pakete vorübergehend zurückhalten.

Sie können Workarounds dokumentieren.

Aber das klingt leichter, als es ist.

Ein kleines Team kann nicht jede Kernelversion auf jeder Kombination aus AMD-, Intel- und NVIDIA-Grafik, Laptop-Firmware, Mainboard, WLAN-Chip, VirtualBox-Version, Secure Boot, DKMS-Modul und angeschlossenem USB-Gerät testen.

Nicht einmal große Projekte schaffen das perfekt.

Dazu kommt der Sicherheitsdruck.

Wenn ein Kernel wichtige Sicherheitsfixes enthält, kann man ihn nicht einfach wochenlang zurückhalten, nur weil irgendwo eine Regression lauert.

Also entsteht ein unangenehmes Dilemma:

Schnell ausliefern und Regressionen riskieren.

Oder zurückhalten und Sicherheitslücken länger offenlassen.

Canonical sitzt dabei am oberen Ende der Entscheidung.

Die kleineren Distributionen sitzen unten und müssen ihren Nutzern erklären, warum die Entscheidung jetzt in ihrem Updatefenster angekommen ist.

Kritik an Canonical ist trotzdem berechtigt

Man muss Canonical zugutehalten, dass das Ubuntu-Kernel-Team die AMDGPU-Regression offen kommuniziert hat.

Das ist besser als Schweigen.

Auch der Hinweis, dass Sicherheitsfixes priorisiert werden mussten, ist nachvollziehbar.

Aber Kommunikation in einem Ubuntu-Forum erreicht nicht automatisch die Menschen, die auf Linux Mint, Zorin OS oder einem anderen Ubuntu-Ableger einfach nur auf „Aktualisieren“ klicken.

Und genau da liegt das Problem.

Wenn ein Kernel mit bekannter Regression ausgeliefert wird, reicht es nicht, dass irgendwo eine technische Erklärung steht.

Dann braucht es eine Kommunikation, die auch die Menschen erreicht, die später betroffen sind.

Besonders dann, wenn man weiß, dass der Ubuntu-Unterbau nicht nur Ubuntu selbst betrifft, sondern auch viele einsteigerfreundliche Downstream-Projekte.

Canonical hat die Ressourcen und die zentrale Position.

Die kleinen Ableger haben oft die Nähe zum Nutzer.

Wenn oben eine Entscheidung fällt, die unten Vertrauen beschädigt, muss oben mehr passieren als ein Forenbeitrag für Menschen, die ohnehin schon tief genug im Thema stecken.

Der Rufschaden trifft häufig die Falschen

Für Canonical ist ein problematischer Kernel ein technischer Vorfall.

Unschön, ja.

Aber analysierbar, korrigierbar, ersetzbar.

Für eine kleine einsteigerfreundliche Distribution kann derselbe Vorfall Vertrauen kosten.

Ein Nutzer erinnert sich später vielleicht nicht daran, dass der Fehler in einem Ubuntu-Kernel steckte.

Er erinnert sich daran, dass sein Rechner nach einem Mint-Update nicht mehr sauber gestartet ist.

Oder dass Zorin plötzlich Kernel Panic zeigte.

Oder dass Linux „wieder so kompliziert“ war.

Und genau das ist gefährlich.

Desktop-Linux hat ohnehin genug Vorurteile am Bein hängen.

„Zu kompliziert.“

„Zu instabil.“

„Nur was für Nerds.“

„Ein Update und alles brennt.“

Wenn ein Einsteiger dann tatsächlich nach einem normalen Update im GRUB-Menü landet, fühlt sich jedes dieser Vorurteile plötzlich bestätigt an.

Selbst wenn das konkrete Projekt gar nicht die eigentliche Ursache war.

Respekt an die, die trotzdem ruhig bleiben

Die eigentliche Leistung beginnt oft erst nach dem Fehler.

Dann sitzen Menschen in Foren, Chats und Communitys und helfen.

Sie erklären, wie man den alten Kernel startet.

Sie sortieren Berichte.

Sie suchen Gemeinsamkeiten.

Sie schreiben Anleitungen.

Sie beruhigen Leute, die Angst haben, ihr System sei zerstört.

Sie trennen echte Kernelprobleme von DKMS-Drama und wilden Zufällen.

Und sie tun das oft für Projekte, die nicht annähernd die Personalstärke von Canonical haben.

Das verdient Respekt.

Nicht nur für Linux Mint.

Auch für Zorin OS, elementary OS, Pop!_OS, TUXEDO OS und all die kleineren Ubuntu-basierten Projekte, die versuchen, Linux für normale Menschen angenehm zu machen.

Einsteigerfreundliches Linux besteht nicht nur aus hübschen Icons und einem guten Installer.

Es besteht auch aus Menschen, die nach einem misslungenen Update ruhig bleiben, während andere innerlich bereits den Rechner aus dem Fenster werfen.

Mein Fazit: Der Unterbau trägt Verantwortung

Ubuntu ist für viele Distributionen ein Fundament.

Und ein Fundament ist nicht sichtbar, solange alles steht.

Man sieht es erst, wenn es Risse bekommt.

Der Kernel 7.0.0-28.28 zeigt ziemlich gut, wie unangenehm solche Risse werden können. Canonical musste Sicherheitsfixes ausliefern, hatte aber gleichzeitig eine bekannte AMDGPU-Regression im Gepäck. Technisch lässt sich das erklären. Für Nutzer bleibt es trotzdem ein schlechtes Erlebnis.

Und für kleine Ubuntu-Ableger bedeutet es Supportarbeit, Frust und möglichen Vertrauensverlust.

Canonical liefert den Kernel.

Aber Mint, Zorin, elementary, Pop!_OS, TUXEDO OS und andere müssen oft die Gesichter beruhigen, die vor dem kaputten Update sitzen.

Das ist nicht fair.

Nicht vollständig vermeidbar.

Aber verdammt nochmal sichtbar genug, um darüber zu reden.

Denn wenn einsteigerfreundliche Distributionen Vertrauen aufbauen sollen, darf der gemeinsame Unterbau nicht regelmäßig dafür sorgen, dass diese Projekte anschließend den Scherbenhaufen erklären müssen.

Ein Kernelupdate sollte langweilig sein.

So langweilig, dass man danach vergisst, dass es überhaupt passiert ist.

Denn der beste Kernel ist nicht der, über den man nach dem Neustart einen Forenthread lesen muss.

Der beste Kernel ist der, bei dem man nach dem Neustart einfach weiterarbeitet.

Und der zweitbeste Kernel ist immerhin der alte im GRUB-Menü.

Quellen und weiterführende Informationen

Tags: #AMDGPU #Canonical #Desktop Linux #elementary OS #GRUB #Kernel 7.0.0-28 #Kernel Panic #Linux Kernel #Linux Mint #Linux Updates #Open Source #Pop!_OS #ROCm #Tech & Basteln #TUXEDO OS #Ubuntu #Ubuntu HWE #Zorin OS