This message was deleted.

Not sure if a hook is the best way. Can you give an example of such a change ?

hi, e.g. adding a kernel module, i would need both hooks correct? to have them available for upgrade and new install

Our goal for kernel modules would be to allow users to rebuild the elemental node image (and include their module). However, a new image means reboot of the node. A "plan" can be deployed at runtime and does not need a reboot.

yes, for that rebuild image i need to consider 2 scenarios. 1. new install 2. upgrade of existing ones. In that case i would need both hooks if i understand correct? in other words is it correct that

after-install-chroot

hooks are ignored during os update?

@hundreds-hospital-60917 I am currently working with @few-jordan-3349 on that topic. Adding kernel modules at runtime (without restarting) does not have prio on our side, right now, but could be a good fit with Plans for future requirements. Currently, we are planning to bundle the drivers at build time. The problem we are facing is to put the drivers (*.ko) files in the right directory /lib/modules/$(uname -r)/kernel/... at build time, as the destination directory is kernel version dependent. (in my case 5.14... for the target system and 5.15... for the machine I use for building the images) That's the reason why we have to apply some artificial step through "cloud-init" moving the drivers to the desired destination folder at runtime. I'm not sure if after-{install,upgrade}-chroot is the right hook, at least in case of an upgrade, as it is executed in the kernel context of the probably replaced kernel. Thus, some early stages after reboot could be a better fit, though, we have to check when the kernel starts to load modules and trigger live loading of these. Any idea to circumvent this? Am I missing something?

Hmm, not sure if the

.ko

file has to go to a kernel-specific directory. If you want to load the module with

modprobe

then sure. But

insmod ./<module>.ko

should work as well 🤔