[Gelöst] Kernel soll trotz "hold" aktualisiert werden.

[ottonormal]

Hallo,

auf dem Rechner meiner Frau wollte ich ein apt update/dist-upgrade durchführen. Dabei will Debian "linux-image-4.19.0-11-amd64" installieren obwohl ich "linux-image-4.19.0-10-amd64" auf hold gesetzt habe:

Code: Alles auswählen

echo linux-image-4.19.0-10-amd64 hold | dpkg --set-selections

Auch in Synaptic ist das Paket gesperrt. Ich möchte aber keinen neuen Kernel, warum wird das nicht akzeptiert, was mache ich falsch?

[schwedenmann]

Hallo

Ist ev. das paket (meta-Paket) linux-image installiert, bzw. bei der insdtallation ausgewählt worden ?

mfg
schwedenmann

[towo]

Es macht halt absolut keinen Sinn, eine Kernel-Image Paket einer bestimmten Version auf hold zu setzen, weil selbiges niemals aktualisiert wird.
Purge die Kernel Meta-Pakete und es wird kein neuer Kernel mehr kommen. Paar Debian Grundlagen zu kennnen ist halt nie verkehrt.

[ottonormal]

Installiert ist:

Code: Alles auswählen

linux-image-4.19.0-10-amd64
linux-headers-4.19.0-10-amd64
linux-image-amd64

Und

"Purge die Kernel Meta-Pakete und es wird kein neuer Kernel mehr kommen."

Das sind "paar Debian-Grundlagen"?

[alberich]

Das sind "paar Debian-Grundlagen"?

Schon irgendwie. Es geht doch anscheinend um den stable Kernel und bei dem Update geht es doch nicht um waghalsige, halsbrecherische neue Kernelfeatures sondern wahrscheinlich auch um Sicherheitsupdates. Warum sollte man das nicht machen?

[schwedenmann]

Hallo

Kernelfeatures sondern wahrscheinlich auch um Sicherheitsupdates. Warum sollte man das nicht machen?

well der TE das nicht will, was sein gutes Recht ist,egal was Debianmantainer wollen. Schließlich gehört dem user der PC und nicht den Mantainern oder der Debiancommunity, wäre ja noch schöner.

mfg
schwedenmann

[mcb]

Installiert ist:

Code: Alles auswählen

linux-image-4.19.0-10-amd64
linux-headers-4.19.0-10-amd64
linux-image-amd64

Und

"Purge die Kernel Meta-Pakete und es wird kein neuer Kernel mehr kommen."

Das sind "paar Debian-Grundlagen"?

Wenn ich es richtig verstehe mußt du linux-image-amd64 auf hold setzen. Kannst du ja mal ausprobieren und dann berichten. Intressiert mich auch ...

hier steht wie es nicht geht:

viewtopic.php?f=27&t=178806

[KP97]

hier steht wie es nicht geht:
viewtopic.php?f=27&t=178806

Doch, da steht wie es geht, Du hast es nur nicht verstanden...;-)

[Tintom]

Da sich solche Threads anscheinend in letzter Zeit häufen: Kann mir jemand den Sinn erklären einen Stable-Kernel auf hold zu setzen? Welche Vorteile verspricht man sich daraus? Ich sehe da nur Nachteile.

[mcb]

hier steht wie es nicht geht:
viewtopic.php?f=27&t=178806

Doch, da steht wie es geht, Du hast es nur nicht verstanden...

Dort steht was ich gemacht habe -> das sollte er dann eben nicht nachmachen in seinem Fall ...

so logisch ist das manchmal eben doch nicht für Anfänger.

[alberich]

Hallo

Kernelfeatures sondern wahrscheinlich auch um Sicherheitsupdates. Warum sollte man das nicht machen?

well der TE das nicht will, was sein gutes Recht ist,egal was Debianmantainer wollen. Schließlich gehört dem user der PC und nicht den Mantainern oder der Debiancommunity, wäre ja noch schöner.

Wer sollte dem widersprechen wollen? Aber Regeln brechen, wenn es denn eine Regel ist, dass man immer den Kernel mit den Sicherheitsupdates haben muss, geht doch am Besten, wenn man weiss, was man da genau tut. Oder ein bisschen wenigstens.

Blöd nur, dass da gleich so ein Gegensatz aufgemacht wird. hier der TE, frei zu tun, was er will, ein Freigeist vor dem Herrn, und dann kommt @alberich daher und pocht kleingeistig auf irgendwelche Regeln, mit einem Heer von ebenso kleingeistigen Maintainern im Schlepptau.

[mcb]

Ev. teilt er uns den Grund ja noch mit.

[ottonormal]

Ev. teilt er uns den Grund ja noch mit.

Der Grund warum ich keine (ständigen?) Kernel-Upgrades will ist der, dass ich auf dem Rechner noch zwei weitere Systeme installiert habe. Grub wird dabei von einem anderen System verwaltet. Da gab es bei einem Kernel-Upgrade immer einiges nachzuarbeiten und das wollte ich mir jetzt ersparen.

Ich habe übrigens jetzt "linux-image-amd64" deinstalliert und damit das Problem gelöst.
Wenn ich die Beiträge zu diesem Faden lese fühle ich mich doch nicht mehr ganz so blöd. Ich meine damit, dass zur Lösung dieses Problems doch wohl etwas mehr notwendig ist als diese "paar Debian Grundlagen".

[Tintom]

Da gab es bei einem Kernel-Upgrade immer einiges nachzuarbeiten und das wollte ich mir jetzt ersparen.

Kannst du ein Beispiel geben? Eigentlich sollte grub alleine alle Schritte abarbeiten können. Wenn er das nicht macht, könnte eine Fehlkonfiguration daran Schuld sein.

[alberich]

Da gab es bei einem Kernel-Upgrade immer einiges nachzuarbeiten und das wollte ich mir jetzt ersparen.

Ah, kenne ich. Bei mir ging es um eine Installation auf einer externen SD Karte, die in Grub eingebuden war. Um es kurz zu machen, `update-grub' und `grub-install' sind da die heißen Kandiaten, um Grub auf dem Laufenden zu halten.

[MSfree]

`update-grub' und `grub-install' sind da die heißen Kandiaten, um Grub auf dem Laufenden zu halten.

update-grub klappert unter Debian die vorhandenen Kernel unter /boot ab und trägt diese in die Datei /boot/grub/grub.cfg ein.

Hat man neben Debian noch ein anderes Linux installiert, das sein /boot auf einer anderen Partition hat, weiß update-grub davon nichts und sucht die Kernel des "Fremdsystems" nicht. Wenn man vorher die Fremdkernel in die grub.cfg von Hand eingetragen hatte, sind diese nach einem update-grub verschwunden.

grub-install braucht man eigentlich nie. Denn das installiert grub neu auf der Festplatte inklusive schreiben eines neuen Bootsektors. OK, gelegentlich gibt es auch neue grub-Versionen, die installiert werden sollten. Aber ansonsten ist einmal installieren im Leben eines Rechners völlig ausreichend. Aber auch hier gilt, hat man mehrere Systeme auf der Platte, die alle ihr eigenes grub-Ding machen, führt das zu Problemen.

[alberich]

`update-grub' und `grub-install' sind da die heißen Kandiaten, um Grub auf dem Laufenden zu halten.

update-grub klappert unter Debian die vorhandenen Kernel unter /boot ab und trägt diese in die Datei /boot/grub/grub.cfg ein.
Hat man neben Debian noch ein anderes Linux installiert, das sein /boot auf einer anderen Partition hat, weiß update-grub davon nichts und sucht die Kernel des "Fremdsystems" nicht. Wenn man vorher die Fremdkernel in die grub.cfg von Hand eingetragen hatte, sind diese nach einem update-grub verschwunden.

Klingt alles so griffig und weise. Meine Erfahrung ist aber eine andere; beide Befehle haben mir bei Problemen mit einem OS auf einer externen SD Karte gut geholfen. Sicher habe ich alles falsch gemacht, aber es hat nun mal gewirkt.

grub-install braucht man eigentlich nie.

Ich schon in dem von mir erwähnten Fall. Aber wahrscheinlich auch nur, weil ich keine Ahnung von irgendwas habe.
Ich hatte das, glaube sogar hier, schon mal besprochen. Passt jetzt auch nicht hierher, weil das ein anderer Thread und ja längst gelöst ist.

[ottonormal]

Auf einem Rechner mit mehreren Systemen habe ich immer ein kleines System, das nur 5 oder 6 GB groß ist. Darauf habe ich den Grub-Customizer installiert, etwas anderes wird darauf nicht genutzt. os-prober habe ich auf keinem System installiert. Jedes System findet bei einem update-grub nur sich selbst. Im Grub-Customizer ist es ja recht einfach möglich manuell ein anderes System hinzuzufügen. Auch grub-install lässt sich von da einfach bewerkstelligen.

Bekomme ich per apt dist-upgrade einen neuen Kernel installiert, kann ich den zwar auch einfach ignorieren, das ist aber ja nicht Sinn der Sache. Will ich den neuen Kernel nutzen, muss ich den Booteintrag auf dem Grub-Customizer-System ändern. Dann hatte ich nach einem Kernel-Upgrade auch schon ein paar mal Probleme mit Virtualbox, das funktionierte danach nicht mehr. Es lässt sich zwar alles wieder reparieren, einfacher ist es aber erst gar keine neuen Kernel zu installieren wenn sie nicht benötigt werden, z.B. bei veränderter (neuerer) Hardware.

[Tintom]

Mir ist nicht ganz klar was du möchtest:

Auf einem Rechner mit mehreren Systemen habe ich immer ein kleines System, das nur 5 oder 6 GB groß ist. Darauf habe ich den Grub-Customizer installiert, etwas anderes wird darauf nicht genutzt.

Das spricht für "ein grub für alle Systeme", aber:

Jedes System findet bei einem update-grub nur sich selbst.

sagt "jedes System für sich".

Was möchtest du? Einer für alle oder alle für sich? Um welche anderen Systeme handelt es sich?

Zugegebenermaßen kenne ich den "Grub Customizer" auch nicht, mein "customizing" habe ich immer nur händisch in den Konfigurationsdateien von grub erledigt.

[ottonormal]

Wenn ich update-grub ausführe, wird nur das eine, eigene System gefunden. Auch auf dem System mit dem Grub-Customizer. Da habe ich aber die Möglichkeit manuell die Booteinträge der anderen Systeme hinzuzufügen und zu speichern. Auch install-grub geht von da aus einfach und schnell.
An Systemen habe ich ein Buster, als Arbeitssystem für meine Frau, dann ein Linux-Mint und ein Openbox-Sparky für die Grub-Geschichte. Eigentlich ist das alles ziemlich einfach und zuverlässig (wenn keine neuen Kernel dazwischenfunken ).

[Tintom]

Wenn ich update-grub ausführe, wird nur das eine, eigene System gefunden.

Möchtest du das weiter so behalten? Falls ja, würde sich os-prober anbieten bzw. dessen Äquivalent für Sparky (da habe ich keine Ahnung von).
Aber da alle Systeme linuxbasiert sind, böte es sich auch an auf dem Basissystem (Sparky) den Grub dergestalt zu konfigurieren, dass von der jeweiligen Partition der Kernel + Initrd geladen wird. Auf den einzelnen Partitionen (Ausnahme Sparky) kann dann grub deinstalliert werden.

Die Frage ist: Was möchtest du?

[alberich]

Dass Grub nur ein System erkennt, kenne ich hinreichend. Debian auf der SD Karte und auf dem Rechner, je nachdem was ich da geupdated habe, Grub war wie Hase und Igel, mal hier mal da. Ich habe mich dann beholfen mit SuperGrub. Wenn ich damit dann ein System boote, die vorher erwähnten Befehle ausführe, sind in Grub alle Einträge vorhanden. Bis zum nächsten Mal jedenfalls... Aber ohne dieses SuperGrub müsste ich es händisch machen, dafür reichen aber meine Nerven nicht aus.

[1] https://www.supergrubdisk.org/

[willy4711]

Hatte mich auch wie ottonormal jahrelang mit einem Triple Boot System und dem grub-customizer herumgeschlagen.
Ist zwar kein großer Aufwand, aber bei 3X Testing muss man halt immer nach einem Kernel-Update dran denken.

Jetzt hab ich nur noch 2 X Debian auf getrennten Platten, und mein Ziel war:

Ohne os-prober und grub-customier sollte mein

• Standart- System automatisch starten.
  Das zweite sollte mit jeweils aktuellem Kernel über den Grub der 1. Platte erreichbar sein.

Beide Systeme haben einen Grub.
Der Grub der 2. Platte wird von der 1. Platte gestartet.

Den Thread dazu - bei Interesse: viewtopic.php?f=29&t=178120

Die schlussendliche Lösung war das Anlegen einer /etc/grub.d/40_custom mit folgendem Inhalt:

Code: Alles auswählen

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Debian Bullseye Mate" {
	insmod ext2
	search --fs-uuid --no-floppy --set=root f8e37245-8f05-4fb5-93bc-e76299146c13
	configfile /boot/grub/grub.cfg
	chainloader +1
}

Seitdem ist wartungsfreie Ruhe.

Das war nun die "Speziallösung" für 2 nvme - SSD's. Ob die bei einer HDD ohne Modifikation funktioniert, glaube ich nicht.

[ottonormal]

Die Frage ist: Was möchtest du?

Ich möchte es genau so behalten, wie es jetzt ist. Das habe ich schon div. Jahre so und keine Problemme damit. Jetzt, wo ich die Installation neuer Kernel unterbunden habe, finde ich es perfekt.
Und nein, os-prober bietet sich für mich nicht an. Das ist ja bei jedem System standarmäßig installiert und eines der ersten Programme, das ich entferne. Meine Methode funktioniert sehr gut ohne.

[Tintom]

Die Frage ist: Was möchtest du?

Ich möchte es genau so behalten, wie es jetzt ist.
[...]

Okay, dann hatte ich es falsch verstanden.