Kernel-Aktualisierungen: warum die gefährlichste Aktualisierung die leiseste ist

Eine Kernel-Aktualisierung wird installiert, die Installation endet ohne Probleme, und nichts sieht verändert aus. Das System läuft weiterhin mit dem alten Kernel, denn ein neuer Kernel greift erst bei einem Neustart.

Und genau dort versteckt sich die Gefahr.

Zwischen Ursache und Wirkung liegen Wochen

Die meisten Paketfehler zeigen sich, während du hinsiehst. Ein Dienst fällt aus, meldet einen Fehler, du merkst es am selben Tag.

Beim Kernel ist das anders. Das Problem erscheint beim nächsten Start, und dieser Start ist womöglich keine geplante Wartungsnacht. Der Strom fällt aus, die Maschine startet sich selbst neu, und sie kommt nicht zurück.

In diesem Moment verbindet niemand das mit "der Aktualisierung von letztem Monat". Was du hast, ist ein unerklärter Ausfall, der überhaupt nicht nach einem Aktualisierungsproblem aussieht.

Das allgemeine Prinzip: das Neue soll nicht Vorgabe sein, bis es sich bewiesen hat

Das ist die übertragbare Lehre dieses Artikels, und sie gilt nicht nur für Kernel.

Ein neuer Kernel darf installiert werden, doch die dauerhafte Vorgabe sollte der alte Kernel bleiben. Der neue sollte nur als "probiere dies einmal beim nächsten Start" ausprobiert werden.

So eingerichtet ändert sich die Gestalt des Fehlers: hängt die Maschine, kehrt sie beim folgenden Start von selbst zum alten zurück. Denn eine einmalige Wahl gilt definitionsgemäß einmal.

Was du gewinnst, ist dies: der Name des Fehlers wird "es ist nichts passiert", nicht "die Maschine ist weg".

Die zweite Schicht: das Installierte soll nicht still zur Vorgabe werden

In dem Moment, in dem ein Kernel installiert ist, sagen die meisten Systeme "ab jetzt starte ich mit dem neuesten". Willst du das nicht, musst du vor der Aktualisierung den laufenden Kernel festnageln.

Das Festnageln blockiert den neuen Kernel nicht, es hindert ihn nur daran, von selbst zur Vorgabe zu werden. Wenn du ihn ausprobieren willst, wählst du.

Die dritte Schicht: wer bemerkt das Hängen

Damit ein Rückfallmechanismus wirkt, muss etwas sagen "diese Maschine ist nicht hochgekommen". Gibt es einen Wächter auf Hardwareebene, tut er das und startet die Maschine neu.

Gibt es keinen, verlangt der Rückfall eine manuelle Rücksetzung. Das macht den Mechanismus nicht nutzlos, aber es muss bekannt sein: der Satz "es fällt automatisch zurück" ist ohne Wächter nur halb wahr.

Die Regel, die auch ohne Produkt gilt

Starte nach einer Kernel-Aktualisierung bewusst und bald neu. Während du hinsiehst.

Ein von dir geplanter Neustart ist ein Test. Ein drei Wochen später vom Stromausfall erzwungener Neustart ist ein Vorfall. Der einzige Unterschied ist, ob du im entscheidenden Moment dabei warst.

Was Atlas tut

Führt Atlas eine Aktualisierung durch, nagelt es standardmäßig den laufenden Kernel fest, damit der neu installierte Kernel nicht von selbst zur Startvorgabe wird. Dieses Verhalten ist nicht zwingend: es wird als Option angeboten, die sich in der Oberfläche abschalten lässt. Das Produkt entscheidet hier nicht, es macht die sichere Seite zur Vorgabe.

Auch der Mechanismus des überprüften Übergangs ist nach dem obigen Prinzip gebaut: die dauerhafte Vorgabe ist immer der alte Kernel, der neue wird nur mit einem einmaligen nächsten Start probiert, und hängt er, fällt das System von selbst zurück. Die Art des Startverwalters wird zur Laufzeit erkannt, denn sie unterscheidet sich von Maschine zu Maschine.

Und zwei ehrliche Grenzen:

Dieser Mechanismus läuft standardmäßig im Beobachtungsmodus. Er sagt also, was er täte, rührt die Startkonfiguration aber nicht an. Tatsächlich einzugreifen ist eine gesonderte Entscheidung.

Gibt es keinen Hardware-Wächter, übergeht der Mechanismus das nicht stillschweigend: er schaltet sich elegant ab und sagt, dass gegebenenfalls eine manuelle Rücksetzung nötig ist. Eine Zusicherung vorzugeben, die es nicht gibt, ist schlimmer, als gar keine zu geben.