Warum werden alte Kernel nach update behalten?

[MoonKid]

Die Diskussion zu dem Thema läuft bereis im Ubuntu-Forum.
http://forum.ubuntuusers.de/topic/warum ... -behalten/

Weil sich herausgestellt hat, dass es ein debian-spezifisches Thema ist, möchte ich hier kurz per X-Post darauf hinweisen.

Das Thema in Kurzform:
Bei apt-get udpate werden neue Kernel-Images aus den offiziellen repositories installiert. Die vorherigen Kernel-Images verbleiben aber im System und verbrauchen Plattenplatz. Das kann bei mobilen Geräten mit kleinen Speicher schon ins Gewicht fallen. Ebenso laufen Debian/Ubuntu-Systeme viele Jahre ohne neu aufgesetzt zu werden. Da sammelt sich was an.

Warum werden die alten Kernel behalten?
Man könnte doch sagen, es reicht, wenn man die letzten 3 oder 5 Kernel behält. Die Installation eines neuen Kernels per update, stösst dann entsprechend die Deinstallation des ältesten Kernels an.

Das Thema betrifft explizit nur die offiziell bereitgestellten Kernel! Selbstgebaute Kernel sollen hiervon natürlich unberührt bleiben.

Das ich das auch per Hand machen kann, ist mir klar. Will ich aber nicht.

Gibt es einen sinnvollen Grund dafür?
Ggf. möchte ich nämlich gerne einen entsprechenden FeauterRequest aufmachen.

[Emess]

Ich war für dieses Feature schon mehrmals Dankbar.
Bei mir kam es schon einige male vor, dass einige Hardware (meist ältere) nicht mehr unterstützt wurden.
Besonders dumm war das, wenn es sich zb. um die Grafikkarte handelte. Wenn man Debian ausschließlich als Desktop nutzt, ist man froh dafür.
Sollte jedoch alles problemlos und besser als zuvor laufen, kann man den alten Kernel ja jederzeit entfernen. ich jeden falls bin froh, dass dies nicht automatisch geschieht.

[rendegast]

Code: Alles auswählen

$ cat /etc/apt/apt.conf.d/01autoremove 
APT
{
  NeverAutoRemove
  {
        "^firmware-linux.*";
        "^linux-firmware$";
        "^linux-image.*";
        "^kfreebsd-image.*";
        "^linux-restricted-modules.*";
        "^linux-ubuntu-modules-.*";
  };

  Never-MarkAuto-Sections
  {
        "metapackages";
        "restricted/metapackages";
        "universe/metapackages";
        "multiverse/metapackages";
        "oldlibs";
        "restricted/oldlibs";
        "universe/oldlibs";
        "multiverse/oldlibs";
  };
};

Begründung, es ist leichter, einen unbenötigten Kernel im Nachhinein zu löschen,
als ein nichtbootbares System wieder mit einem Kernel auszustatten.


Wenn Du es denn möchtest, könntest du obiges auskommentieren und damit experimentieren.
Jedoch werden die kernel-Pakete wohl über ihren alias "linux-image" bei entsprechendem Meta-Paket gehalten.

Ich habe es sogar noch erweitert

Code: Alles auswählen

APT::NeverAutoRemove:: "^linux-headers.*";
APT::NeverAutoRemove:: "^linux-kbuild.*";
APT::NeverAutoRemove:: "^linux-patch-debian.*";
APT::NeverAutoRemove:: "^linux-support.*";

[MoonKid]

Alle beiden Vorposter treffen meinen use-case nicht.
Ich will nicht alle alten Kernel gelöscht haben. Das ich als backfall, mindestens einen behalten muss ist mir klar.

Debian/Ubuntu sollte einfach per default die letzten 3 oder 5 behalten. Mehr nicht.

In diesem Fall würde das Problem mit der nicht-unterstützen Hardware vom ersten Poster nicht so schwer wiegen. Es sind noch einige alte Kernel da.

Die Lösung des zweiten Posters würde alle alten Kernel löschen. Das wäre natürlich fatal und in keinem Fall sinnvoll.

[guennid]

Du willst nicht alle Kerne, sondern alle bis auf die letzten 3-5 automatisch deinstalliert haben. Ich denke, in der Endstufe suchst du sowas, bei dem ein Huhn, abgerichtet darauf, sich seine Körner von der Enter-Taste zu picken, die Rechnerarbeit übernehmen kann.

Nimm's mir nicht übel, aber ich halte dein Begehren für reichlich unpraktisch. Nach welchen Kriterien soll da jetzt sinnvoll eine Zahl festgelegt werden? Oder wäre dir ne config lieber, in der du deine Präferenzen einträgst? Niemand hindert dich daran, deine alten Kerne zu löschen. Schließe mich voll Emess an.

Grüße, Günther

[maledora4]

Bei apt-get udpate werden neue Kernel-Images aus den offiziellen repositories installiert

Code: Alles auswählen

# apt-get update

hat bei mir noch NIE was installiert.

Nach Deiner Schreibweise "fressen" auch 3-5 Kernel genuegend Plattenplatz.

[Natureshadow]

Denk mal darüber nach, was dein Wunsch für das Paketsystem bedeutet. Das geht nicht.

-nik

[rendegast]

Code: Alles auswählen

$ aptitude search "?installed ~Plinux-image" -F "%p"
linux-image-2.6.32-5-amd64
linux-image-2.6.32-5-xen-amd64
linux-image-3.2.0-0.bpo.4-amd64
linux-image-3.2.0-4-amd64
linux-image-3.6-trunk-amd64
linux-image-3.8-trunk-amd64

Du könntest Dir ein Skript ausgehend von solch einer Ausgabe basteln.
Eingebunden vielleicht über sowas bei jedem Install-Vorgang

Code: Alles auswählen

DPkg::Post-Invoke:: "apt-get clean";

oder per daily-Job.

[owl102]

Nimm's mir nicht übel, aber ich halte dein Begehren für reichlich unpraktisch. Nach welchen Kriterien soll da jetzt sinnvoll eine Zahl festgelegt werden? Oder wäre dir ne config lieber, in der du deine Präferenzen einträgst?

Wieso nicht, Fedora macht es z.B. genau so. Siehe: http://docs.fedoraproject.org/en-US/Fed ... ories.html (dort unter "installonly_limit=value" schauen)

[guennid]

Wieso nicht

sagte ich schon .

Fedora macht es z.B. genau so

Und das macht es jetzt sinnvoll, oder wie?

Tut mir leid,Leute! ich bin froh, dass Debian über ein solches feature nicht verfügt. Und falls es das hier je geben sollte, dann doch hoffentlich abschaltbar.

Grüße, Günther

[Emess]

Tut mir leid,Leute! ich bin froh, dass Debian über ein solches feature nicht verfügt. Und falls es das hier je geben sollte, dann doch hoffentlich abschaltbar.

Grüße, Günther

Zustimm aber 100%

[owl102]

Und das macht es jetzt sinnvoll, oder wie?

Habe ich "sinnvoll" geschrieben? Davon ab ging es doch um dein "reichlich unpraktisch", und nicht um "sinnvoll".

Tut mir leid,Leute! ich bin froh, dass Debian über ein solches feature nicht verfügt. Und falls es das hier je geben sollte, dann doch hoffentlich abschaltbar.

Wenn es abschaltbar ist, oder aber sogar per default abgeschaltet ist, was spricht dagegen? (Ich persönlich finde es übrigens ganz praktisch.)

[Cae]

Wenn /boot zum Beispiel auf fest eingebautem Flash liegt (und liegen muss), waere man schon froh, wenn nur der aktuelle plus der letzte Kernel als Fallback installiert waeren, weil der dritte Kernel einfach keinen Platz mehr hat. Auf der anderen Seite kann's ja durchaus gewollt sein, aeltere Kernel zum Testen, wegen bestimmter Hardware oder aus sonstigen Gruenden zu behalten; automatisches Entfernen waere in diesem Sinne bevormundend und potenziell destruktiv.

Gruss Cae

[guennid]

Findet ihr nicht, dass das langsam eine ziemlich alberne Diskussion im Forum "Fortgeschrittene Themen, Unterforum Kernelfragen" wird.

[wanne]

Denk mal darüber nach, was dein Wunsch für das Paketsystem bedeutet. Das geht nicht.

Zumindest rpm kann's (Fedora, Mageia) also so problematisch scheint es nicht zu sein.
Ich glaube die haben ein dummy paket, das kernel-latest das immer von den letzten beiden kernelversionen abhägt. Dadurch werden immer die letzten beiden erhalten. Und sinnvoll finde ich das auch. Das system wird nicht zugemüllt aber man hat immer ein backup. Eingreifen muss man dann nur wenn was schiefläuft aber man hat trotzdem die Möglichkeit ein kaput geupdatetes System zu booten.
Und natürlich installiert apt-get update Pakete (Oft haben neuere Versionen andere Abhängigkeiten.)

[Cae]

Ich glaube die haben ein dummy paket, das kernel-latest das immer von den letzten beiden kernelversionen abhägt. Dadurch werden immer die letzten beiden erhalten.

Das finde ich ziemlich genial. Man muss nur irgendwie dafuer sorgen, dass dieses Paket beim ersten Kernelupdate mitinstalliert wird oder andersrum vom Installer mit dem Depends auf nur den Erstlingskernel bereit gestellt wird. Konflikte mit irgendwelchen selbst installierten Kernelpaketen sind damit ausgeschlossen.

Gruss Cae

[Emess]

Was ist denn eigentlich so schwierig dabei?
Es gibt en Kernelupdate und der alte Kernel bleibt erhalten. irgendwann stellt man fest, dass der neue Kernel all das macht was er soll.
Also purgt man den alten und fertig. Für mich ist das so schnell passiert, dass ich da nix automatisieren muss!

[r900]

Und natürlich installiert apt-get update Pakete (Oft haben neuere Versionen andere Abhängigkeiten.)

Da scheint jemand update mit upgrade zu Verwechseln.

Falls man so eine Funktion wirklich braucht würde ich so etwas hier als cron-job ausführen:

Code: Alles auswählen

#!/bin/sh
keep=3
current=$(uname -r)
kernels=$(dpkg -l | egrep -o 'linux-image-[0-9]+[^ ]*' | sort -rV)
num=$(echo "$kernels" | wc -l)
if [ $num -gt $keep ]; then
  for kernel in $(echo "$kernels" | tail -n -$((num - keep))); do
    [ "$kernel" != "linux-image-$current" ] && apt-get -qsy remove $kernel
  done
fi

Aber vorher natürlich ein wenig testen. Deshalb hat apt-get noch die Option "s", damit wird nur simuliert was passieren würde.

Wem das zu langweilig ist der möge beim sort-Kommando das "r" durch ein "R" ersetzen.

[wanne]

Da scheint jemand update mit upgrade zu Verwechseln.

Da hat mich wohl jemand ertappt.

[MoonKid]

Ich glaube die haben ein dummy paket, das kernel-latest das immer von den letzten beiden kernelversionen abhägt. Dadurch werden immer die letzten beiden erhalten.

Ja, das klingt nach einer schönen Lösung.

Mein ihr ein FeauterReqeust bei Debian würde ersntgenommen werden? (Was natürlich nicht unbedingt heißt, dass es auch realisiert wird.)

[r900]

Mein ihr ein FeauterReqeust bei Debian würde ersntgenommen werden?

Kann ich mir bei Debian jedenfalls nicht vorstellen. Wie bereits erwähnt wurde ist der Kernel eine relativ kritische Sache und das macht der admin (in dem Fall also du!) lieber selbst. Mit dem cron-Skript weiter oben erreichst du doch genau was du willst.

Bei Ubuntu könntest mit einem feature request bessere Chancen haben. Aber so oder so müsstest du eine Datei editieren um die eventuelle Funktion zu aktivieren. Und auch das müsste irgendwo dokumentiert werden. Also warum nicht gleich einen cron-job anlegen, gepaart mit einem kurzen Wiki-Eintrag?

[reba]

Ach Leute,

persönliche Bequemlichkeit ist ja gut und schön.
Aber ein System, das mir funktionierende Kernel bei einem dist-upgrade automatisch löscht, bevor ich Gelegenheit habe, den neuen mit all meiner Hardware und Anpassungen ausführlich zu testen, gehört in die Tonne.
Wer nichts selber machen/bedenken möchte, ist sicher bei ChromeOS oder anderen Cloud-Systemen besser aufgehoben.
Und bevor jetzt der Gutmenschen-Flame kommt: manche ar beiten auch mit Computern!

[owl102]

Aber ein System, das mir funktionierende Kernel bei einem dist-upgrade automatisch löscht, bevor ich Gelegenheit habe, den neuen mit all meiner Hardware und Anpassungen ausführlich zu testen, gehört in die Tonne.

"keep=3". Wenn du der Meinung bist, du bräuchtest aber unbedingt auch den viert-ältesten Kernel als Rückfallebene, kannst du es anpassen, oder das Script einfach überhaupt nicht verwenden.

Aber gleich von Tonne und ChromeOS zu reden führt IMHO am eigentlichen Thema vorbei.

[reba]

"keep=3". Wenn du der Meinung bist, du bräuchtest aber unbedingt auch den viert-ältesten Kernel als Rückfallebene, kannst du es anpassen, oder das Script einfach überhaupt nicht verwenden.

Aber gleich von Tonne und ChromeOS zu reden führt IMHO am eigentlichen Thema vorbei.

Doch! Es geht nämlich darum, wer entscheidet, was auf meinen Rechnern installiert ist und was nicht.

[owl102]

Doch! Es geht nämlich darum, wer entscheidet, was auf meinen Rechnern installiert ist und was nicht.

Genau. Ich entscheide, daß ich nur die letzten 3 Kernel behalten möchte. (Mein /boot ist sowieso begrenzt.) Du entscheidest, daß du alle Kernel behalten möchtest und löscht ggf. selber. Beides wäre möglich.