Kernel im aktiven System nachladen (ohne Reboot)

Ich mal wieder

Kennt jemand den Weg, einen Kernel nachzuladen?

Hab irgendwo im Netz mal aufgeschnappt (keine Ahnung wo) dass es einen Panic-Kernel gibt ( ->geben KANN), der bei ner Panic geladen wird.

Dann wärs schon fast trivial, dem Kernel weismachen er fahre Panic und nächste Instanz starten.

Das simple starten eines [unkomprimierten] Kernels führt verständlicherweise zu "Speicherzugriffsfehler" und Beendigung der zweiten Instanz.

Bevor die Frage nach dem wieso kommt:

Der Build einiger Packages in chroot Umgebung führt sicher oder ziemlich sicher zum Misserfolg (bspw. QT)

Es gibt Packages, die im Buildprozess gerne noch was nachladen (usbutils zum Bleistift).

Ziel: den Reboot vermeiden und trotzdem in "nativer" Umgebung weiter bauen können, mit WWW Connection und dem Orig Kernel des Sys.

Hat jemand mehr zu dem Thema "aufgeschnappt" als ich?

HJS

Quote from jsffm

Offen gestanden kann ich mir das nicht vorstellen, wenn überhaupt, muss er binär identisch sein.

Wieso?

Seit einiger Zeit ist der Kernel relozierbar (als default), ich lade also schlicht ein Programm nach.

Binär identisch? Der neue Kernel ist der Chef, der init aufruft etc pp, wozu binär identisch? Ich will den alten Kernel nicht einfach mit sich selbst überschreiben, das ergäbe keinen Sinn und den genannten eh nicht :o

Der nachzuladende Kernel ist der Boss und der Alte Geschichte.

HJS

M-Reimer Thx, die .20 zickt, aber die .19 wirds hoffentlich tun

wirbel Fallstricke hats immer und überall.

Das "Durchcompilieren" wird eh meinen lfshost vorraussetzen, damit ich sicher bin, den richtigen Ausgangskernel zu haben.

Wenns sein muss, bau ich halt mit vorgegebener config nen Kernel auf LFS und der geneigte User bekommt "seinen" Kernel ganz am Ende

Die andere Option, ohne reboot durchzukommen, wäre natürlich:

1. booten aus initrd, und die linuxrc erst verlassen, wenn das Basissystem vollständig ist.

Nachteil(e) :

- kein jobctrl bis init übernimmt

- network manuell hochfahren, sonst keine Sourcen

2. Einen Host kreieren, der bspw. aus /LFSHOST/{bin,/usr/bin,...} operiert und das LFS quasi "neben" dem Host zu installieren.

Nachteil(e) :

- ob da wirklich alle packages beim "--prefix=/LFSHOST" mitspielen ?!

Vorteil(e) :

Wenns klappt, wohl die zuverlässigste Variante

HJS

Quote from M-Reimer

Keine Ahnung was du vorhast, aber systemd hat eine Lösung für Updates beim Booten. Man bereitet alles vor und triggert einen Reboot. Während dem Booten werden dann die Updates installiert. Mindestens Ubuntu und Fedora (und dann auch RedHat) nutzen das.

hab ich doch beschrieben. Ich will sowohl chroot als auch reboot vermeiden

HJS