Linux kexec vom Live System möglich?

[Ambrosius]

Hab hier so einen Edge Case, wo ich ein Live Linux im RAM geladen habe und ein (signifikant( neuerer Kernel verfügbar ist.
Vielleicht ist es das eine Dumbatz Frage, aber wer weiss, manchmal sind die komischsten Dinge möglich.
Könnte ich also mit kexec den neuen Kernel laden und die Live Umgebung irgendwie konservieren?

 

[zwieblum]

kexec(8) - Linux manual page

Du musst das aber in der Initrd ausführen, wenn ich mich richtig erinnere.
Edit: Nö, muss man nicht, aber man muss "kexec-tools" installiert haben

Beitrag automatisch zusammengeführt: 30 Mai 2026

hm ... debian paket mit neuem Kernel in persistenter Partition speichern, beim Booten den Kernel installieren und dann mit kexec laden? Sollte eigendlich problemlos funktionieren, sofern die initrd mit allen tools für's livesystem gebaut werden kann (suqashfs, overlayfs ...)

 

[Ambrosius]

, sofern die initrd mit allen tools für's livesystem gebaut werden kann (suqashfs, overlayfs

Wie kann ich das herausfinden?
Das ist sicher nicht distro-agnostisch, oder?

 

[zwieblum]

Wenn deine ISO selfcontaining ist, dann hast du alle Tools mit an Bord. Ich hab' refractasnapshot, das baut eine spezielle Version der initrd. Wenn du live-build nimmst sollte da auch so was drinnen sein (ich hab's nur nie verwendet). Spaßig wird's dann später wenn die initrd pivotroot machen möchte: die Kernelmodule, die nicht in der initrd sind, liegen in overlay aka ramdisk, die ist aber mit dem alten kernel entsorgt worden. IMO gibt's da einen Hook in den live-tools für's automounten eines persistenten overlays --> richtig konfiguriert nimmtman eine partition für's overlay über / und da sind vom alten Overlay auch die im alten Overlay installierten Pakete wieder an der richtigen Stelle. ... funktioniert aber nur mit usb-storage o.ä. .... oder man packt alle Kernelmodue in die neue initrd und mountet die dann über /ib/modules/... ist sicher einfacher als eine Ramdisk mit fixer Startadresse/Größe für beide Kernel

Using the RAM disk block device with Linux — The Linux Kernel documentation

www.kernel.org

 

[Ambrosius]

Ok ich seh schon, da ist doch weitaus mehr dahinter, als ich anfänglich gedacht habe. Der initrd Prozess (danke für den Link) ist mbMn ein guter Ansatz und könnte durchaus klappen. Das erfordert aber mehr Hintergrundwissen über den gesamten Linux Bootprozess, der bei mir nur mittelmäßig vorhanden ist.
Eine Quick and Dirty Lösung gibt es wohl nicht dafür. Ich hatte mich nämlich ursprünglich an den Wiki Artikel orientiert gehabt und gedacht man könne den System Call einfach aus der Shell aufrufen mit ein paar veränderten Parametern die die live Umgebung miteinbeziehen, so wie hier:

kexec -l /boot/vmlinuz-linux --initrd=/boot/initramfs-linux.img --reuse-cmdline

Aber dem ist scheinbar nicht so. Der Artikel ist eher kurz gehalten und orientiert sich vornehmlich an SystemD was ich so in der Form nicht gebrauchen kann.

Danke @zwieblum für deine Ideen, ich muss mir aber wohl n anderen Workaround ausdenken.

 

[zwieblum]

kexec wird von der Shell aus ausgeführt, aber statt "kexec -e" sollte man "reboot" nehmen, damit alles sauber entfernt wird.

kexec -l /boot/vmlinuz-linux-neu --initrd=/boot/initramfs-linux-neu.img --command-line="$(cat /proc/cmdline|sed 'mach-was-interessantes')"
reboot

Das systemd-gedröhns im Artikel kannst du getrost ignorien Wenn du ein Flag für e.g. /etc/rc.local nach kexec brauchst kannst das einfach an die commadline ranhängen, e.g. "... ich_wurde_mit_kexec_gestartet".

 

[bob7]

Könnte ich also mit kexec den neuen Kernel laden und die Live Umgebung irgendwie konservieren?

Nein, nachdem man mit kexec einen anderen Kernel geladen hat, muss man trotzdem in diesen booten. Man spart sich im Gegensatz zu einem regulären Reboot nur den Ausflug über die EFI-Firmware.

Was Du vmtl. eigentlich möchtest ist so etwas wie LBU von Alpine Linux. Damit lässt sich der aktuelle Zustand sichern, wenn man diskless gebootet hat, und nach einem Reboot wieder einspielen.