Debian Kernel Update: Wie alten Kernel bzw. Module behalten?

[stillebucht]

Hallo,

unter Debian bekommen Kernel Updates ja keine neuen Paketnamen, sodass bei der Installation der vorhandene Kernel samt Modulen überschreiben wird. Wenn man dann nicht umgehend neu startet, kann es zu Problemen mit den Kernelmodulen kommen, weil die nun auf der Festplatte installierten Dateien nicht mehr zum laufenden Kernel passen.

Kurz zu meinem Hintergrund und warum mich das erstaunt: Ich betreibe eine Reihe von Systemen mit Debian Stable. Für einige ARM-Geräte kompiliere ich die Kernel selbst (automatisiert) und habe es dort so gelöst, wie ich es von Ubuntu her kannte (das war ein Einstieg in die Linux Welt, inzwischen habe ich aber fast alle Systeme auf Debian umgestellt). Dort erhält jedes Kernel Image seinen eigenen Paketnamen, sodass sich die unteschiedlichen Versionen nicht in die Quere kommen und man nach einem Kernel Update in Grub auch die Möglichkeit hat, eine ältere Version zu booten. Für meine x86-basierten Systeme nutze ich den in Debian mitgelieferten Kernel.

Als Problem aufgefallen ist mir das Update-Verhalten von Debian Kerneln erst am Samstag, als ich nach dem Kernel Update, welches Teil des Point Releases 8.7 war, nicht sofort neu gestartet hatte (ich wollte den Rechner eine Stunde später ohnehin runterfahren) und danach aber keine CIFS-Freigaben mehr mounten konnte, weil das Kernel-Modul nicht geladen werden konnte (hat eine Weile gedauert, bis ich das kapiert hatte, weil die Fehlermeldung von mount.cifs natürlich erst mal eine andere war). Kurzum: Dies ist das erste Mal, dass ich mit das Standardverhalten bzw. die Vorgaben von Debian nicht für sinnvoll halte (systemd stört mich beispielsweise nicht). Nicht nur, dass man im laufenden Betrieb Probleme mit Kernel Modulen erhalten kann, sondern auch, dass man keine Möglichkeit hat, nach deinem Kernel Update noch eine ältere Version booten zu können, erscheint mir wenig robust.

Daher frage ich mich, ob es möglich ist, dass von Ubuntu bekannte Verhalten auch unter Debian irgendwie nachzustellen. Ich habe bereits einen Blogbeitrag [1] gefunden, der zeigt, wie man mittels eines preinst-Skripts Backups des alten Kernels anlegt. Allerdings werden dort nur die Dateien unter /boot/ gesichert, aber keine Kernel Module. Die Kernel Module an einen neuen Ort zu kopieren wäre auch kein Problem. Aber wie würde ich einem Kernel dann mitteilen, dass er seine Module nicht mehr utner "/var/lib/modules/3.16.0-4-amd64/" findet, sondern z.B. unter "/var/lib/modules/3.16.0-4-amd64~backup/"? Gibt es da eine Möglichkeit, das über die Bootparameter einzustellen? Ich konnte da bisher nichts finden...

Danke und schöne Grüße

Timo

[1] https://codeyellow.nl/debian-kernel-update-backup.html

[Tintom]

Der Stable-Kernel wird erhält innerhalb eines Releases idR nur aufgrund von Sicherheitsfixes Updates. Die Frage ist eher: Warum möchtest du einen unsicheren Kernel starten?

[scientific]

Mir wär es neu, dass man Debian nicht mit unterschiedlichen Kerneln booten könnte.
Dann hat das gestern also nicht funktioniert und war nur eine optische Täuschung???

[stillebucht]

Der Stable-Kernel wird erhält innerhalb eines Releases idR nur aufgrund von Sicherheitsfixes Updates. Die Frage ist eher: Warum möchtest du einen unsicheren Kernel starten?

In der Regel möchte man das natürlich nicht. Aber es ist ja nicht so, dass es bei Updates nie zu Problemen kommen könnte, sodass die Möglichkeit, im Zweifel den vorherigen Kernel zu booten, schon nützlich sein kann.

Das ist mir aber gar nicht unbedingt der wichtigste Aspekt an der Sache. Wichtiger wäre mir, dass man nach Installation eines Kernel-Updates auch bis zum nächsten Reboot normal weiterarbeiten kann, sprich, dass die Moduldateien nicht einfach überschrieben werden und nicht mehr zum laufenden Kernel passen. Auch das kann man wohl mittels eines preinst-Skriptes lösen (ich dachte da an Umbenennen/Verschieben des Modulordners und dann, wenn die neuen Module installiert sind, die alten Module über ein postinst-Skript nochmal vorübergehend als overlay am bisherigen Ort mounten bis zum Reboot). Aber schöner wäre natürlich eine Lösung, die beides bietet - also problemloses Weiterarbeiten nach Update bis zum Reboot und Möglichkeit zum Booten des vorherigen Kernels im Notfall. Da weiß ich im Moment leider noch keinen Weg...

[nudgegoonies]

Alles hat Vor- und Nachteile. Bei Debian kannst Du so viele Kernels haben wie Du willst. Aber der Standard-Debian Kernel wird genauso "aktualisiert" wie normale Debian Pakete. Darum gibt es da immer nur einen. Das Verhalten das Du beschreibst kenne ich von Debian und ich darum reboote ich nach jedem Kernel-Update auch sofort bzw. verzögere ich die Aktualisierung bis ich eh runterfahre.

Das Ubuntu-Verhalten sorgt spätestens nach 20 Kernel Updates für platzende Boot-Partitionen, weil die meisten Leute die Veralteten Kernel nach dem erfolgreichen Reboot nicht löschen.

Sowohl bei Debian als auch bei Ubuntu gibt es aber das Problem, dass es immer nur eine linux-libc-dev gibt. Die versioniert selbst Ubuntu nicht so, dass es zu mehreren Kernels unterschiedliche Versionen auf dem selben System gibt.

[stillebucht]

Mir wär es neu, dass man Debian nicht mit unterschiedlichen Kerneln booten könnte.
Dann hat das gestern also nicht funktioniert und war nur eine optische Täuschung???

Du täuschst dich nicht, aber du hast das Problem auch nicht verstanden.

Selbstverständlich kann man in Debian unterschiedliche Kernel installieren und diese dann beim Booten auswählen. Wenn du dir neben dem Stable-Kernel z.B. einen anderen aus den Backports oder einen selbst kompilierten Kernel installierst, klappt das. Das Problem ist aber, wenn du nur den Stable-Kernel installiert hast und diesen dann aktualisierst, dann bleibt da keine vorherige Version mehr übrig, weil die Dateien einfach überschreiben werden. Der Paketname ändert sich bei Stable-Kernel-Updates nicht.

Ein Beispiel, um es ganz deutlich zu machen: Das Kernel-Paket für Stable ist dieses hier: https://packages.debian.org/jessie/linu ... .0-4-amd64
Aktuell ist die Version 3.16.39-1, die letztes Wochenende freigegeben wurde. Die vorherige Version war 3.16.36-1+deb8u2. Der Paketname ändert sich beim Update aber ebensowenig (linux-image-3.16.0-4-amd64) wie der Installationsort der Dateien: https://packages.debian.org/jessie/amd6 ... 4/filelist
Module werden weiterhin im Ordner /lib/modules/3.16.0-4-amd64/ installiert und auch das Kernelimage heißt weiterhin /boot/vmlinuz-3.16.0-4-amd64 - egal welche der beiden Versionen du nun installiert hast. Sprich, beim Update werden die vorhandenen Dateien einfach überschrieben und du kannst die vorherige Version nicht mehr booten, weil sie einfach nicht mehr da ist.
Das mag in der Testing Distribution anders sein, wenn es z.B. ein größeres Update von 4.7 auf 4.8 gibt - denn da hast du ja unterschiedliche Paketnamen und Installationsorte. Bei Ubuntu ist das auch anders. Da bekommt jedes Update seinen eigenen Paketnamen und Installationsort und es gibt ein Metapaket, dass die jeweils neueste Version als Abhängigkeit definiert. Das bringt natürlich den Nachteil mit sich, dass man die alten Kernel auch von Zeit zu Zeit aufräumen sollte, da sie eben nicht automatisch überschreiben bzw. gelöscht werden.

Mein Frage ist nun, wie kann ich bei einem Update den vorigen Stable-Kernel samt Modulen sichern, sodass ich diesen auch ggf. in Grub noch auswählen und booten könnte...

[guennid]

Das Problem ist aber, wenn du nur den Stable-Kernel installiert hast und diesen dann aktualisierst, dann bleibt da keine vorherige Version mehr übrig, weil die Dateien einfach überschrieben werden.

Das passiert aber nur, wenn du das Kernel-Metapaket installiert hast. Löschst du das, wird dir Debian bei keinem Update mehr den laufenden Kernel überschreiben.

Im Übrigen sollte man vor einem tatsächlichen upgrade dieses mit dem Parameter -s simulieren, dann weiß man vorher, was passieren würde, wenn...

Die andere Methode wäre, den Kernel auf hold zu setzen.

[Tintom]

Das Problem ist aber, wenn du nur den Stable-Kernel installiert hast und diesen dann aktualisierst, dann bleibt da keine vorherige Version mehr übrig, weil die Dateien einfach überschrieben werden.

Das passiert aber nur, wenn du das Kernel-Metapaket installiert hast. Löschst du das, wird dir Debian bei keinem Update mehr den laufenden Kernel überschreiben.

Um das Metapaket ging es dem TE ja gerade nicht

Ich sehe keinen anderen Weg (weil offiziell nicht so vorgesehen), als das von dir verlinkte Skript zu erweitern um einen Eintrag für den Ordner /lib/modules/<Kernelversion>

[rendegast]

Idee per btrfs

/boot
/lib/modules
als subvols

Vor dem Kernelupgrade ein snapshot des System mit
/boot (old)
/lib/modules (old)

Sodaß
rootflags=subvol=....
das / mit den entsprechenden /boot / /lib/modules zusammengestellt wird.


Technisch vielleicht eher (siehe als Beispiel suse LEAP) entsprechend vorbereitet,
ein /-Subvolume mit (nur)
/boot
/lib/modules
und ALLE anderen Ordner in / als einzumountende Ordner-Subvolumes (entsprechende /etc/fstab).
So fehlen aber wohl wichtige Ordner beim Booten?



Alternative Idee mit grub
grub-Shell kann doch auch Dateisysteme verändern.
Es existieren Links
/boot -> boot.curr
/boot.curr/
/boot.bak/
/lib/modules -> modules.curr
/lib/modules.curr/
/lib/modules.bak/
und von grub über eine commandline-Option angewiesen der Link entsprechend modifiziert wird(?).
Das scheint mir aber in der Boot-Phase ein heißes Eisen.
EDIT Da habe ich mich wohl sehr weit aus dem Fenster gelehnt,
grub kann diverse Dateisysteme LESEN, die grubenv schreiben ( ist das wirklich eine Dateisystemoperation oder ein block-Schreiben? ), und Partitionseinträge modifizieren.
Linkmodifikation gibt es wohl nicht.

[guennid]

Hmmm

Um das Metapaket ging es dem TE ja gerade nicht

Mag sein, dass das Thema für mich ein wenig zu hoch hängt. Aber ich meine, so etwas wie den umgekehrten Fall erlebt zu haben, also dass selbst bei einem dist-upgrade der kernel gerade nicht upgegraded wurde, eben weil kein Meta-Paket installiert war. Und wenn ich recht sehe, kann er, so lange er das alte image nicht aus /var/cache/apt/archives gelöscht hat, dieses jederzeit wieder reinstallieren. Wenn ich den aktuellen Kern gleichzeitig hätte benutzen wollen, hätte ich mir den unter anderem Namen auf Grundlage der vorhandenen config selbst kompiliert (um Modifiaktionen kommt er doch eh nicht herum, wenn ich ihn recht verstanden habe) und unter diesem Namen installiert.

[Tintom]

Hmmm

Um das Metapaket ging es dem TE ja gerade nicht

Mag sein, dass das Thema für mich ein wenig zu hoch hängt. Aber ich meine, so etwas wie den umgekehrten Fall erlebt zu haben, also dass selbst bei einem dist-upgrade der kernel gerade nicht upgegraded wurde, eben weil kein Meta-Paket installiert war.

Das mag sein und ist auch soweit logisch, aber nach dist-upgrade war ja gar nicht gefragt. Es ging darum, dass sich der Paketname des aktuellen Kernels bei einem Update nicht ändert.
Dein Vorschlag, die alte Version wieder zu installieren, bedeutet ja, dass ich die alte Kernelversion über die neue überschreibe - aber `uname -r` bleibt ja gleich und ändert sich nicht. Somit hätte man sich das Update auch sparen können.

Wenn ich den aktuellen Kern gleichzeitig hätte benutzen wollen, hätte ich mir den unter anderem Namen auf Grundlage der vorhandenen config selbst kompiliert (um Modifiaktionen kommt er doch eh nicht herum, wenn ich ihn recht verstanden habe) und unter diesem Namen installiert.

Das ist natürlich die eleganteste (und aufwändigste) Lösung, aber ob der TE die will?!

[stillebucht]

Danke für die vielen Antworten.

Das Problem ist aber, wenn du nur den Stable-Kernel installiert hast und diesen dann aktualisierst, dann bleibt da keine vorherige Version mehr übrig, weil die Dateien einfach überschrieben werden.

Das passiert aber nur, wenn du das Kernel-Metapaket installiert hast. Löschst du das, wird dir Debian bei keinem Update mehr den laufenden Kernel überschreiben.

Bei der Stable Distribution dürfte das eigentlich keine Rolle spielen. Denn da definiert das Metapaket ja kein neues Kernelpaket als Abhängigkeit, sondern das Kernelpaket selbst wird aktualisiert und so würde man es es ebenfalls zum Aktualisieren angeboten bekommen. Bei einem Upgrade auf die nächste Stable-Version spielt es aber natürlich eine Rolle, da dann nur mittels des Metapakets der neuere Kernel installiert wird. In der Testing Distribution sieht das natürlich ganz anders aus...

Die andere Methode wäre, den Kernel auf hold zu setzen.

Vorerst habe ich das so gemacht, ja.

Idee per btrfs

/boot
/lib/modules
als subvols

Darauf bin ich noch gar nicht gekommen. Das ist eigentlich eine sehr elegante Lösung. Aber aktuell habe gegenüber BTRFS noch Vorbehalte, vielleicht ändert sich das mit Stretch.

Alternative Idee mit grub
grub-Shell kann doch auch Dateisysteme verändern.
[...]
Das scheint mir aber in der Boot-Phase ein heißes Eisen.

Auch das ist interessant. Für das Bootverzeichnis ist das gar nicht nötig. Da kann man die Dateien mit eindeutigen Namen versehen, sodass man nur den Symlink für die Module aktualisieren müsste. Das schaue ich mir mal an, wie das funktioniert. Aber ggf. würde es schon reichen, dass ich den Symlink im Bedarfsfall beim Booten manuell ändern könnte.

Wenn ich den aktuellen Kern gleichzeitig hätte benutzen wollen, hätte ich mir den unter anderem Namen auf Grundlage der vorhandenen config selbst kompiliert (um Modifiaktionen kommt er doch eh nicht herum, wenn ich ihn recht verstanden habe) und unter diesem Namen installiert.

Naja, ein Neukompilieren würde ich gern vermeiden, denn letztlich möchte ich am Kernel selbst ja gar nichts ändern und das wäre dann wohl etwas "Overkill". Das einfachste wäre es, man könnte einem Kernel mittels Bootparameter mitteilen, wo die Module gespeichert sind. Dann hätte sich das Problem in Luft aufgelöst. Aber das scheint es nicht zu geben. Insofern muss man da doch etwas kreativer werden...

Ich sehe keinen anderen Weg (weil offiziell nicht so vorgesehen), als das von dir verlinkte Skript zu erweitern um einen Eintrag für den Ordner /lib/modules/<Kernelversion>

Ja, so sehe ich das im Moment auch.

[rendegast]

Ich sehe keinen anderen Weg (weil offiziell nicht so vorgesehen), als das von dir verlinkte Skript zu erweitern um einen Eintrag für den Ordner /lib/modules/<Kernelversion>

Ja, so sehe ich das im Moment auch.

Scheint mir unter den Voraussetzungen am praktikabelsten,
im besten Fall bootet der backup-kernel und kann das Modulverzeichnis des current-kernel einfach benutzen,
im schlechten Fall wäre noch eine Umbenennung des Modulverzeichnis unter live-System nötig.

Statt eines live-System könnte auch ein dritter beliebiger kernel vorliegen,
der nur diesem Zweck dient.
Dazu muß der auch nur in 'single' booten, oder einen entsprechenden custom-Runlevel oder -unit mit nur ssh.