[aufgegeben] Mehr als 2 Kernel / apt purge löscht den Kernel unter /boot

[mcb]

Hola,

ich benutze den Backport Kernel unter Buster (und bin zufrieden)

habe jetzt 5.7 und 5.8 drauf (gehen auch beide) -

nun hatte apt autoremove mir vorgeschlagen den stable Kernel 4 zu entfernen. Da mein /boot mit 1 GB ausreicht habe ich mit:

Code: Alles auswählen

root@mb:/home/marc# apt purge linux-image-4.19.0-10-amd64 -y 

dem Kernel 4 nur aus der Configuration entfernen wollen (dachte der bleibt auf boot liegen) ?

Jetzt ist er weg Was habe ich nicht bedacht ?

Könnte ich apt nicht auf 4 oder 6 Kernel setzen, bevor autoremove aufräumt?

PS: Ich habe mein System kürzlich neu aufgesetzt. Hier war die Info mit apt purge:

Kernel von updates ausschließen - debianforum.de
viewtopic.php?f=34&t=178259

[mcb]

PS:

Code: Alles auswählen

df / /boot/ /home/ -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/VG-root   33G  7.4G   24G  24% /
/dev/nvme0n1p5       923M  104M  756M  13% /boot
/dev/mapper/VG-home  307G  121G  172G  42% /home

Falls noch Ausgaben, Infos oder ... fehlen bitte Anfordern.

[willy4711]

Jetzt ist er weg Was habe ich nicht bedacht ?

Was erwartest du denn, wenn du ein Image (=Kernel) löschst ????

Könnte ich apt nicht auf 4 oder 6 Kernel setzen, bevor autoremove aufräumt?

Brauchst ja autoremove nicht ausführen.
Wenn du so versessen auf einen Kernel-Sammlung bist, kannst du ja die alten Kernel auf hold setzen.
Hab ich zwar noch nie gemacht, sollte aber funktionieren.

[mcb]

Ja ok -

dann habe ich den anderen thread falsch verstanden - aber ist ja nichts schlimmes passiert, das System läuft noch (Hauptsache) .........

Verständnisfrage auf hold setzen dachte das ist synonym für nicht aktuallisieren ?

z.B.

Code: Alles auswählen

apt-mark showhold
thunderbird
root@mb:/home/marc# 

[willy4711]

Verständnisfrage auf hold setzen dachte das ist synonym für nicht aktuallisieren ?

Wenn du ein Paket auf hold setzt, wird es, "vereinfacht" gesprochen, von der Paketverwaltung nicht mehr beachtet.
Dies schließt auch autoremove ein.
Die Frage bleibt, warum man mehr als zwei Kernel auf seinem System bereithalten will.
Ich sehe da keinen praktischen Nährwert drin.

[mcb]

Verständnisfrage auf hold setzen dachte das ist synonym für nicht aktuallisieren ?

Wenn du ein Paket auf hold setzt, wird es, "vereinfacht" gesprochen, von der Paketverwaltung nicht mehr beachtet.
Dies schließt auch autoremove ein.
Die Frage bleibt, warum man mehr als zwei Kernel auf seinem System bereithalten will.
Ich sehe da keinen praktischen Nährwert drin.

OK, das solte auch gehen - zwei Kernel sind auch in Ordnung. Linuxneuland

[michaa7]

@apt-mark hold

Wenn du ein konkretes Kernel-image-paket auf hold setzt, dann verhinderst du *nicht* die Installation eines neuen Kernels. Ein neuer Kernel ist *keine* neue Version des alten Kernels, sondern ein neues, ein anderes Paket mit anderem Namen. Und das wird über ein meta-Paket hereingezogen, nicht über den alten Kernel.

Ich habe das noch nicht praktisch in allen Einzelheiten so durchgeführt, aber genau so sollte es funktionieren.

[mcb]

@apt-mark hold

Wenn du ein konkretes Kernel-image-paket auf hold setzt, dann verhinderst du *nicht* die Installation eines neuen Kernels. Ein neuer Kernel ist *keine* neue Version des alten Kernels, sondern ein neues, ein anderes Paket mit anderem Namen. Und das wird über ein meta-Paket hereingezogen, nicht über den alten Kernel.

Ich habe das noch nicht praktisch in allen Einzelheiten so durchgeführt, aber genau so sollte es funktionieren.

ja ich durchdenke das seit ein paar Stunden, habe die apt-mark Anleitung gelesen und bin grade gefrustet - du hast wahrscheinlich recht, entweder kommt dann kein Kernelupdate oder wenn ich es händisch installiere greifen die Mechanismen (nur 2 Kernel) ev. wieder.

Irgendwo in den Tiefen von Debian / apt kann man die Limitierung von 2 Kerneln anheben. Nur wie ???

[Tintom]

Irgendwo in den Tiefen von Debian / apt kann man die Limitierung von 2 Kerneln anheben. Nur wie ???

Es gibt keine Limitierung auf zwei Kerne.

EDIT: Sorry, ich habe das nicht im Kontext gelesen. Diese "Limitierung" auf zwei Kerne im Zusammenhang mit autoremove ist eine Einstellungssache von apt, namentlich in der Datei /etc/apt/apt.conf.d/01autoremove-kernels.

[MSfree]

EDIT: Sorry, ich habe das nicht im Kontext gelesen. Diese "Limitierung" auf zwei Kerne im Zusammenhang mit autoremove ist eine Einstellungssache von apt, namentlich in der Datei /etc/apt/apt.conf.d/01autoremove-kernels.

Dieses Limit bezieht sich aber auf Kernel mit der gleichen Revisionsnummer. So wird z.B. von der 4.9-Kernelserie jeweils nur der aktuelle und der vorherige aufgehoben. Sollte also beim Reboot mit dem aktuellen Kernel Probleme auftreten, kann man noch den alten Kernel booten.

Installiert man aber Kernel aus den Backports, kann man so viele Kernel installieren, wie angeboten werden, da gibt es kein 2-Kernel-Limit.

[willy4711]

MSfree war schneller
Das Entfernen von Kernel 4.19.0-10 (bzw. der Vorschlag von autoremove) liegt wohl auch daran, dass dieser nicht mehr
in der Liste der zu schützenden Kernel steht.
Meine /etc/apt/apt.conf.d/01autoremove-kernels schützt die Kernel der Serie 5.8.0-xxxx
Das ist zwar jetzt Testing, aber bei den Backports-Kernel wird es wohl ähnlich aussehen.
Ich denke mal dass diese Kernel dann auch erhalten bleiben.
Hatte es selbst schon das dann mal 4 Stück versammelt waren, bevor ich die händisch purgte.
Waren dann allerdings alle aus der selben "Serie" also z.B. 5.7.x

Einen etwas tiefer greifenden Artikel gibt es bei den Ubuntus:
https://askubuntu.com/questions/563483/ ... ld-kernels

[Tintom]

Achso ok, dann lag ich falsch. Ich dachte dem TE ging es gerade genau um diese 2-Kernel-Limitierung.

[mcb]

Danke! So sieht es aus

PS. um den 4er Kernel ist es nicht schade ... und ich bin letztendlich selbst verantwortlich dafür welcht Befehle ich eintippe

Code: Alles auswählen

marc@mb:~$ cat /etc/apt/apt.conf.d/01autoremove-kernels 
// DO NOT EDIT! File autogenerated by /etc/kernel/postinst.d/apt-auto-removal
APT::NeverAutoRemove
{
   "^linux-image-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-image-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-image-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-headers-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-headers-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-headers-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-image-extra-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-image-extra-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-image-extra-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-modules-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-modules-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-modules-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-modules-extra-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-modules-extra-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-modules-extra-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-signed-image-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-signed-image-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-signed-image-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-image-unsigned-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-image-unsigned-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-image-unsigned-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^kfreebsd-image-5\.7\.0-0\.bpo\.2-amd64$";
   "^kfreebsd-image-5\.8\.0-0\.bpo\.2-amd64$";
   "^kfreebsd-image-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^kfreebsd-headers-5\.7\.0-0\.bpo\.2-amd64$";
   "^kfreebsd-headers-5\.8\.0-0\.bpo\.2-amd64$";
   "^kfreebsd-headers-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^gnumach-image-5\.7\.0-0\.bpo\.2-amd64$";
   "^gnumach-image-5\.8\.0-0\.bpo\.2-amd64$";
   "^gnumach-image-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^.*-modules-5\.7\.0-0\.bpo\.2-amd64$";
   "^.*-modules-5\.8\.0-0\.bpo\.2-amd64$";
   "^.*-modules-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^.*-kernel-5\.7\.0-0\.bpo\.2-amd64$";
   "^.*-kernel-5\.8\.0-0\.bpo\.2-amd64$";
   "^.*-kernel-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-backports-modules-.*-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-backports-modules-.*-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-backports-modules-.*-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-modules-.*-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-modules-.*-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-modules-.*-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-tools-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-tools-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-tools-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-cloud-tools-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-cloud-tools-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-cloud-tools-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-buildinfo-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-buildinfo-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-buildinfo-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
   "^linux-source-5\.7\.0-0\.bpo\.2-amd64$";
   "^linux-source-5\.8\.0-0\.bpo\.2-amd64$";
   "^linux-source-5\.8\.0-0\.bpo\.2-amd64-unsigned$";
};
/* Debug information:
# dpkg list:
ii  linux-image-4.19.0-10-amd64              4.19.132-1                          amd64        Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-5.7.0-0.bpo.2-amd64          5.7.10-1~bpo10+1                    amd64        Linux 5.7 for 64-bit PCs (signed)
iF  linux-image-5.8.0-0.bpo.2-amd64-unsigned 5.8.10-1~bpo10+1                    amd64        Linux 5.8 for 64-bit PCs
ii  linux-image-amd64                        5.7.10-1~bpo10+1                    amd64        Linux for 64-bit PCs (meta-package)
# list of installed kernel packages:
4.19.0-10-amd64 4.19.132-1
5.7.0-0.bpo.2-amd64 5.7.10-1~bpo10+1
5.8.0-0.bpo.2-amd64-unsigned 5.8.10-1~bpo10+1
# list of different kernel versions:
5.8.10-1~bpo10+1
5.7.10-1~bpo10+1
4.19.132-1
# Installing kernel:  (5.8.0-0.bpo.2-amd64)
# Running kernel: 5.7.10-1~bpo10+1 (5.7.0-0.bpo.2-amd64)
# Last kernel: 5.8.10-1~bpo10+1
# Previous kernel: 5.7.10-1~bpo10+1
# Kernel versions list to keep:
5.7.10-1~bpo10+1
5.8.10-1~bpo10+1
# Kernel packages (version part) to protect:
5\.7\.0-0\.bpo\.2-amd64
5\.8\.0-0\.bpo\.2-amd64
5\.8\.0-0\.bpo\.2-amd64-unsigned
*/
marc@mb:~$ 

Jetzt bin ich etwas schlauer, die Limitierung auf 2 Kernel finde ich zwar noch nicht -> ?!?

Möglichkeiten:

1) kein apt autoremove
2) Metapaket deinstallieren
3) Metapaket auf hold setzen

Ich würde gerne erreichen das z.B. der 5.7.10 (der lief Wochenlang ohne Problem) einfach drauf bleibt ("für immer")

und dann 3 neuere von denen immer der letzte gelöscht wird z.B.

oder

die Automatik ganz aus und ich deinstalliere einzelne per Hand, das habe ich ja nun gelernt. zumindest das Löschen

[KP97]

Dieses "Durcheinander" wird von dem Kernel-Metapaket erzeugt und Deinem falschen Verständnis, was ein solches Metapaket eigentlich macht.
Deinstalliere das Metapaket.
Dann wird nichts mehr automatisch installiert und Du hast die komplette Kontrolle über Deine installierten Kernel.
Wenn Du meinst, nun hab' ich aber genug altes Zeug auf meinem Rechner, der Platz wird langsam eng, dann räumst Du mal auf.
Und nicht mit autoremove sondern mit apt purge.

Ob es einen neuen Kernel gibt, kannst Du manuell in der Paketdatenbank oder mit Synaptic abfragen.

/OT
Bitte in Deinen Antworten nicht immer die Vollzitate. Das ist sehr störend, da wir den Kram direkt vorher schon gelesen haben.
Wenn Du Dich auf etwas beziehen willst, zitiere ausschließlich das Wort bzw. den Satz.

[mcb]

Dieses "Durcheinander" wird von dem Kernel-Metapaket erzeugt und Deinem falschen Verständnis, was ein solches Metapaket eigentlich macht.
Deinstalliere das Metapaket.
Dann wird nichts mehr automatisch installiert und Du hast die komplette Kontrolle über Deine installierten Kernel.
Wenn Du meinst, nun hab' ich aber genug altes Zeug auf meinem Rechner, der Platz wird langsam eng, dann räumst Du mal auf.
Und nicht mit autoremove sondern mit apt purge.

Ob es einen neuen Kernel gibt, kannst Du manuell in der Paketdatenbank oder mit Synaptic abfragen.

OK danke ! Metapaket ist mir wirklich nicht 100% klar (ich bin kein Informatiker).

Bevor ich mir das Wochenende versaue (durch Unwissen):

Bitte der passende code

[mcb]

Das tut mir leid mit den Zitaten - Teilzitate gingen bisher immer schief ...

So ich suche das Metapaket:

Code: Alles auswählen

dpkg --list | grep linux-image
ii  linux-image-5.7.0-0.bpo.2-amd64          5.7.10-1~bpo10+1                    amd64        Linux 5.7 for 64-bit PCs (signed)
ii  linux-image-5.8.0-0.bpo.2-amd64-unsigned 5.8.10-1~bpo10+1                    amd64        Linux 5.8 for 64-bit PCs
ii [b] linux-image-amd64                        5.7.10-1~bpo10+1                    amd64        Linux for 64-bit PCs (meta-package)[/b]
marc@mb:~$ 

Code: Alles auswählen

marc@mb:~$ apt purge linux-image-amd64 -s 
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-image-amd64*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Purg linux-image-amd64 [5.7.10-1~bpo10+1]
marc@mb:~$ 

Das hatte ich mit dem 4er schon -> ev. ist er dann weg.

[willy4711]

Das Meta-Paket für den Stable-Kernel ist linux-image-amd64 (4.19+105+deb10u6).
Das hast du auch gar nicht gepurgt, sondern einen bestimmten Kernel.

Das Meta-Paket des Stable Release wurde mit ziemlicher Sicherheit deinstalliert, als du den Backport-Kernel installiert hast.
Von da ab steuert das Meta-Paket aus den Backports die Kernel-Updates.

Keinen Ahnung, warum du das Meta-Paket aus den Backports nun purgen willst.

Kannst du das mal begründen ?

[mcb]

Das Meta-Paket für den Stable-Kernel ist linux-image-amd64 (4.19+105+deb10u6).
Das hast du auch gar nicht gepurgt, sondern einen bestimmten Kernel.

Das Meta-Paket des Stable Release wurde mit ziemlicher Sicherheit deinstalliert, als du den Backport-Kernel installiert hast.
Von da ab steuert das Meta-Paket aus den Backports die Kernel-Updates.

Keinen Ahnung, warum du das Meta-Paket aus den Backports nun purgen willst.

Kannst du das mal begründen ?

Das wurde vorgeschlagen - um die "Liemitierung" der Kernel aufzuheben ..................

Ich gebe zu mir fehlt viel Wissen (ev. ist das auch nicht so logisch mit apt, autoremove, metapaket und co )

Ich gebe erstmal auf.

Steht auf der 1sten Seite (ich bekomme das nicht auf die Reihe mit dem Zitiren): "Ich würde gerne erreichen das z.B. der 5.7.10 (der lief Wochenlang ohne Problem) einfach drauf bleibt ("für immer")

und dann 3 neuere von denen immer der letzte gelöscht wird z.B.
"

per Hand einzelne Kernel löschen wäre auch ok!

[KBDCALLS]

Ich selbst nutze zwar aptitude , da einfach flexibler. Außerdem löscht apt-get autoremove manchmal einfach zuviel. Da kanns passieren das Pakete gelöscht werden , die eigentlich noch benötigt werden. Da muß man schon genau hinsehen was der vorhat. Und im Zweifel lieber abbrechen. Und bei heutigen Plattengrößen spielt selbst 1 GB keine Rolle. Anders ausgedrückt autoremove ist überflüssig, und könnte eigentlich erszatzlos gestrichen werden.

[willy4711]

Ich gebe erstmal auf.

Steht auf der 1sten Seite (ich bekomme das nicht auf die Reihe mit dem Zitiren): "Ich würde gerne erreichen das z.B. der 5.7.10 (der lief Wochenlang ohne Problem) einfach drauf bleibt ("für immer")

Irgendwann fängt der an zu verschimmeln und überträgt dann den Pilz auf andere Pakete

Spass beiseite: Ich würde es so lassen wie es ist. Und dann beobachten, was passiert.
Sollte der Kernel 5.7.10 dann irgendwann von autoremove vorgeschlagen werden, kannst du es ja
ablehnen bzw testen, was passiert, wenn du den auf hold setzt.

[mcb]

Ja ich lasse autoremove erstmal weg und schaue was passiert (so oft kommen die Kernel ja nicht).

- hätte zwar gerne meine Idee automatisiert, aber das läuft ja nicht weg. Und im Zweifel startet der 2te Kernel, von dem könnte man wieder weiter zurück (im Fall der Fälle).

[willy4711]

Und im Zweifel startet der 2te Kernel, von dem könnte man wieder weiter zurück (im Fall der Fälle).

[/quote]

Hast du schon mal im Grub-Menü in der "erweiterten Optionen gesehen ?
Ein installierter Kernel ist auch von dort startbar.
Weiter zurück als da zur Auswahl steht, geht nicht.

[mcb]

Und im Zweifel startet der 2te Kernel, von dem könnte man wieder weiter zurück (im Fall der Fälle).

Hast du schon mal im Grub-Menü in der "erweiterten Optionen gesehen ?
Ein installierter Kernel ist auch von dort startbar.
Weiter zurück als da zur Auswahl steht, geht nicht.
[/quote]

Ja das kenne ich -> falls der neue nicht geht -> alten starten z.B. 5.7 und im System (im Fall der Fälle) 5.6 installieren ...