debianforum.de

Hallo,
mich stört das in der Überschrift beschriebene Verhalten, da z.B. mal ein Kernelupdate den Suspend an meinem Samsung-Netbook zerstört hatte (Systemabsturz nach Suspend) und ich deswegen mühsam die ältere Kernelversion besorgen musste. Bin erst seit Wheezy dabei- in früheren Version war dies wohl anders? Wünschenswert wäre für mich, wenigstens die n jüngsten Versionen zu behalten. Weiß jemand, wie das in jessie geplant ist, bzw. wie man auf die Verantwortlichen einwirken kann? Wird es fortgesetzt, wie in Wheezy? Als Zwischenlösung habe ich folgendes preinstall-Skript gefunden, habe es aber bisher nicht getestet. Eine in die Paketverwaltung integrierte Lösung erscheint mir darüber hinaus robuster...

http://www.codeyellow.nl/debian-kernel- ... ackup.html
Gruß
spawndebian

Beim Auto-Upgrader unattended-upgrades gibt es die Möglichkeit, Pakete auszuschließen,
'apt-config dump | grep -i blacklist':
Probleme nach einem Suspend sollten eigentlich nur entladene / neu zu ladende Module betreffen,
da der im Speicher befindliche Kernel weiterläuft.
Nach einem Reboot sollten Probleme nur auftauchen, wenn das Kernel-Upgrade nicht vollständig durchgelaufen ist,
was eigentlich "nur" die Erstellung der initrd betreffen sollte
(wird das neue Kernel-Image nicht nach /boot/ geschrieben, so liegen dort ja weiterhin vmlinuz und initrd des vorherigen Kernels).
Sicherheitshalber halte ich den Standardkernel UND den backports-kernel vor,
ein Systemstart sollte dann immer möglich sein.

Vorheriges vmlinuz und initrd könnten auch in der Art vmlinuz.bak / initrd.bak behalten werden,
ein Bezug darauf ist beim Booten durch einfaches Editieren des grub-Eintrages möglich.
Automatisiert vielleicht durch ein Skript in /etc/kernel/preinst.d/ ?

Du könntest die entsprechenden Pakete auch auf hold setzen. Beispiel

Ich bin hier zwar nicht so firm wie viele andere hier im Forum, aber nach meinem Dafürhalten kannst du das sehr einfach verhindern, indem du den aktuellen Kern per apt-mark auf hold setzt. DANACH würde ich wie rendegast verfahren, d.h. bei Bedarf den zu ersetzenden Kern sichern und schauen, welche Unarten der neue hat.

Grüße, Günther

Bei mir bleiben die alten Kernel auf dem System, wenn ein neuer kommt. Kann man auch irgendwo konfigurieren. Grundsätzlich ist’s nicht die beste Idee, den Kernel festzunageln und damit u.U. nach einiger Zeit mit einem System offen wie ein Scheunentor umherzubrowsen.

Ist das den auch bei Sicherheitsaktualisierungen so? Ich dachte das trifft nur auf neuere Versionen (also gewöhnlich in testing und sid) zu. Bei einem Sicherheitsupdate wird der alte Kernel einfach entsorgt.

Zumindest habe ich ’ne ziemlich lange Liste unter Wheezy im Grub-Menü (weil ich zu faul bin, aufzuräumen) und jeder davon ist startbar.

Stimmt, habe gerade mal in den logs geschaut die Vorgängerversion bleibt. Klar muss ja auch so sein da der Paketname anders ist und sich die beiden Pakete nicht gegenseitig ausschließen.

Grundsätzlich ist’s nicht die beste Idee, den Kernel festzunageln und damit u.U. nach einiger Zeit mit einem System offen wie ein Scheunentor umherzubrowsen.

Jepp! Ich hätte noch erwähnen sollen, dass ich meistens selbstkomplilierte Kerne verwende und die baue ich schon aus neueren Quellen. Aber der Standardkern bleibt immer drauf und da habe ich keine Lust auf ständige Udates, weil ich den eh nur testweise verwende, wenn neue hardware mit dem Eigenbaukern erst mal zickt.

Grüße, Günther

niemand hat geschrieben:Zumindest habe ich ’ne ziemlich lange Liste unter Wheezy im Grub-Menü (weil ich zu faul bin, aufzuräumen) und jeder davon ist startbar.

Das ist interessant. Ich habe, wie auch aus dem Eingagspost hervorgeht, in meinem Wheezy eine ziemlich kurze Liste: Den momentanen Kernel und dessen Recoverymode (und 'nen Memtest, glaub ich).
In /boot hab ich äquivalent dazu auch nur jeweils einen Eintrag für initrd.img-3.2.0-4-amd64 und den entsprechenden vmlinuz etc.
Womit updatest du denn dein System? Ich hab bei mir ganz bequem den update-notifier so konfiguriert, dass Sicherheitsupdates automatisch installiert werden. Ist dein System eine Neuinstallation oder ein Upgrade aus einer alten Debianversion heraus?


Das "apt-mark hold PAKTET" benutze ich ja momentan, aber es wäre schon praktisch, so lange Kernelupdates installieren zu können, bis was kaputt geht (oder eben nicht..) und dann auf die letzte Version ausweichen zu können

rendegast hat geschrieben: Vorheriges vmlinuz und initrd könnten auch in der Art vmlinuz.bak / initrd.bak behalten werden,
ein Bezug darauf ist beim Booten durch einfaches Editieren des grub-Eintrages möglich.
Automatisiert vielleicht durch ein Skript in /etc/kernel/preinst.d/ ?

Ja, ok, was hältst du denn von dem Skript im Eingangspost (bin noch Bash-Anfänger...)

Womit updatest du denn dein System? Ich hab bei mir ganz bequem den update-notifier so konfiguriert, dass Sicherheitsupdates automatisch installiert werden. Ist dein System eine Neuinstallation oder ein Upgrade aus einer alten Debianversion heraus?

aptitude und das System war eine native Wheezy-Installation via debootstrap. Das Verhalten mit den Kerneln kann man konfigurieren, hab’s aber nicht mehr im Kopf, wie genau man das macht – eine Suchmaschine wird dir sicher gerne weiterhelfen.

niemand hat geschrieben:

Womit updatest du denn dein System? Ich hab bei mir ganz bequem den update-notifier so konfiguriert, dass Sicherheitsupdates automatisch installiert werden. Ist dein System eine Neuinstallation oder ein Upgrade aus einer alten Debianversion heraus?

aptitude und das System war eine native Wheezy-Installation via debootstrap. Das Verhalten mit den Kerneln kann man konfigurieren, hab’s aber nicht mehr im Kopf, wie genau man das macht – eine Suchmaschine wird dir sicher gerne weiterhelfen.

Die Suchmaschine hab ich vor dem Post bereits ausführlich bemüht... Werde beim nächsten Kernelupdate mal schauen, was er mit aptitude machen will.

Hab mir jetzt mal den Spaß erlaubt und nen älteren Kernel installiert. Ergebnis:
- aptitude möchte den Kernel genauso ersetzten
- das preinstall-Skript funzt...

Wenn ich mich recht erinnere, passiert das nur, wenn man ein Kernel-Metapaket installiert hat.
Das solltest Du entfernen und stattdessen das gewünschte Kernelpaket installieren.
Also so:

inux-image-686-pae - Linux für moderne PCs (Metapaket)

linux-image-3.16.0-4-686-pae - Linux 3.16 for modern PCs

Dann wird auch nichts entfernt und der alte Kernel bleibt bei einem Update immer erhalten.

Hab die beiden Pakete

linux-image-amd64
linux-headers-amd64

entfernt (purge)

Der neue Kernel soll leider immer noch den alten ersetzen...

Wenn es ein Sicherheitsupdate für die aktuell laufende Version ist, dann ja.
Wenn es eine andere, ältere oder neuere Version, z.B. aus den Backports ist, dann bleibt die aktuell laufende Version auf dem System erhalten.