[solved] Unhold kernel vor dist-upgrades?

[whiizy]

Frohes neues Jahr,

ich habe hier noch einen Audio-Laptop mit Stretch und meinem selbstgebauten Debian-Realtime-kernel laufen. Ich plane den Laptop schrittweise erst auf Buster und dann Bullseye hochzuziehen. Der selbstkompilierte kernel wurde beim Bau automatisch auf "hold" gesetzt und ist vermutlich deshalb immer der aktive kernel geblieben, auch wenn bei Updates immer brav die Distributions-kernel aktualisiert wurden (über die metapackages linux-image-amd64 und linux-image-rt-amd64). War auch so gewünscht.

Mit dpkg -l sieht der hold-status ("hi") in etwa so aus:

Code: Alles auswählen

[...]
hi  linux-image-4.9.privat
ii  linux-image-amd64     
ii  linux-image-rt-amd64 
[...]

Würde es reichen, meinen speziellen Kernel auf "unhold" zu setzen, damit wieder die gewöhnlichen kernel aus linux-image-amd64 aktiv werden können? z.B. mit apt-mark unhold linux-image-4.9.privat?

Ich würde dadurch gerne sicherstellen, daß die dist-upgrades auf buster und bullsseye unter dem Standardkernel ablaufen. Fernziel wäre unter bullseye schließlich den 5er-kernel erneut realtime-optimiert zu bauen.

Kann das so gelingen? Hat jemand "unhold" schonmal in dieser Weise genutzt?

[fischig]

Ich vermute, du denkst hier zu kompliziert (Humoristisch ausgedrückt: Vielleicht ist dir hier der Verstand im Wege )
Ich verwende auf den meisten Systemen eigene Kerne. Ich erinnere mich nicht, dass bei einem dist-upgrade ein Kern jemals automatisch entfernt worden wäre, egal ob selbst gebaut oder automatisch installiert, ob auf hold gesetzt oder nicht. Es wird immer automatisch immer nur der zum Release passende neue Kern installiert, abhängig davon, ob im vorhergehenden Release der Metakern installiert war oder nicht. Falls kein Metakern installiert war, installierst du den passenden Standardkern eben nach (und/oder installierst den Meta, je nachdem, was du kernelmäßig automatisiert haben möchtest). Welchen der vorhandenen Kerne ich (als default) starten will, stelle ich im bootloader ein. Die Kerne, die ich nicht mehr haben will, deinstalliere ich händisch.

Alles ohne Gewähr. Das Problem, wie du es siehst, hatte ich einfach noch nie.

Und dann viel Spaß beim Sprung von 4.9 auf 5.10 beim Eigenbau!

[whiizy]

Danke, ich fürchte hier ist eher, wie so oft, mein Unverständnis im Wege

Ich habe wohl einfach nicht ganz durchschaut, wie der debian build es damals geschafft hat, daß der eigene Kernel über so lange Zeit immer der default geblieben ist. Beim weiteren Nachdenken kann das eigentlich nicht nur das Setzen auf Hold gewesen sein - schützt das gebaute kernel-Paket ja nur vor Löschung.

Vielmehr sollte es an der grub config liegen. Laut meiner /etc/default/grub wird der erste kernel aus der Liste geladen "GRUB_DEFAULT=0".

Schaue ich in die entsprechende /boot/grub/grub.cfg ist dort der erste und einzige menuentry der selbstgebaute kernel.

Alle weiteren kernel, also die Metakernel und zuvorderst auch nochmals mein buildkernel, sind nur im submenu als menuentries gelistet. Diese Einträge kann man bekanntlich im Startmenue von grub über "Advanced options for Debian GNU/Linux" aufklappen und dann starten lassen. -

Du hast vielleicht recht, daß das Upgrade von stretch auf buster das schon irgendwie vernünftig managen würde. Aber ich erlebe ungerne Überraschungen im Bereich kernel, gerade beim Upgrade einer Maschine, an der mir liegt. Deshalb möchte ich den Normalkernel aus linux-image-amd64 gerne vor dem dist-upgrade wieder als default-kernel eingerichtet wissen.

Momentan ist mir noch unklar, wie ich den Normalkernel erstmal wieder sauber zum GRUB_DEFAULT machen kann ... (?)

[whiizy]

Glaube jetzt verstanden zu haben, wieso der gebaute debiankernel immer der default geblieben ist!
Im grub manual findet sich etwas versteckt ein Hinweis, nach welchem Kriterium die submenues generiert werden:

‘GRUB_DISABLE_SUBMENU’

Normally, grub-mkconfig will generate top level menu entry for the kernel with highest version number and put all other found kernels or alternative menu entries for recovery mode in submenu. For entries returned by os-prober first entry will be put on top level and all others in submenu. If this option is set to ‘true’, flat menu with all entries on top level will be generated instead. Changing this option will require changing existing values of ‘GRUB_DEFAULT’, ‘fallback’ (see fallback) and ‘default’ (see default) environment variables as well as saved default entry using grub-set-default and value used with grub-reboot.

Demnach wird immer der Kernel mit der höchsten Versionsnummer ins Hauptmenue geschrieben. Alle anderen wandern ins submenu. Die höchste Versionsnummer hat immer noch mein Selbstgebauter:

vmlinuz-4.9.189-rt131
vmlinuz-4.9.0-17-amd64
vmlinuz-4.9.0-17-rt-amd64

Wenn ich jetzt auf buster upgrade, würde über das metapackage dessen normaler vmlinuz-4.19.x installiert. Da dessen Versionsnummer somit größer würde, sollte er automatisch an erster Position im grub menue landen. Wäre also genau das, was ich übergangsweise anstrebe!

Der alte hold gesetzte Kernel bliebe zwar noch installiert, würde aber von buster nicht mehr benutzt.

Oder habe ich da jetzt noch was übersehen?

[fischig]

Einstellen des automatisch zu bootenden Kerns in grub ist etwas tricky. Habe ich schon wieder vergessen, wie das geht. Da ich kein EFI habe/benutze, nehme ich meistens lilo. Da ist das einfacher. Mit EFI funktioniert lilo nicht mehr! Jedenfalls ist das meiner Meinung nach alles, worum du dich kümmern musst: Bootloader-Konfiguration. Deinen Kernen passiert nichts beim Upgraden.

[whiizy]

Liest sich so, als hättest du meinen vorherigen post noch nicht gesehen, als du das geschrieben hast. Meinem Verständnis nach ist ein manueller Eingriff ins grub menue in meinem Szenario jetzt nicht mehr nötig, wenn automatisch die höhere kernelversion während des dist-upgrades auf buster an Position 1 wandert.

Das System bootet übrigens über EFI und das soll auch so bleiben.

Grüsse

[fischig]

Meinem Verständnis nach ist ein manueller Eingriff ins grub menue in meinem Szenario jetzt nicht mehr nötig, wenn [...]

Gelesen hatte ich das schon. Aber auf das wenn kommt's an. Der manuelle Eingriff in einen der beiden genannten Bootloader ist NIE nötig, WENN man mit dem, was der loader will, einverstanden ist. Aber das kann man immer ändern, WENN man das will.

Das System bootet übrigens über EFI und das soll auch so bleiben.

Deswegen hatte ich die Einschränkung bei lilo genannt, aber du warst dir unsicher bei deiner Grub-Konfiguration, deswegen wollte ich lilo wenigstens genannt haben.

[whiizy]

Upgrade auf buster hat geklappt, running kernel ist nun automatisch linux-image-4.19.0-18-amd64 geworden. Von dieser Standard-Basis aus steht jetzt auch dem nächsten upgrade auf bullseye nichts mehr im Wege.