Repository navigation
dkms fails to build modules in chroot with a different kernel, depending on scriptlet #605
Description
Activity
Hello, a pull request is fine, thank you.
Just a note on the logic; based on the same logic of not targeting the running kernel, what would then be the difference on a physical host?
I think at that point, targeting the running kernel would not make sense, probably just targeting all kernels found on an actual system would be the more logic behaviour even on a physical system.
I like the idea of targeting all the kernels, but that's a little more complicated. There is a
autoinstall_all_kernelsvariable inframework.confthat is not read by dkms, justcommon.postinst. A quick look at the code showed several places that reference${kernelver[0]}which implies to me (but would need to look deeper to be sure) that there are still some code paths that don't yet support performing their action on mutiple kernels.Let's assume, for now, that multi-kernel actions are out of scope and can be tackled as a future enhancement.
If I'm on a "normal" host without the headers for my running kernel, and I install a package-dkms rpm, I would expect it to fail and complain loudly. No matter what kernel it chooses it probably won't be loadable in the current boot. But inside a chroot/container, I have no expectation that it's going to try to load the module on the current kernel (we turn off
modprobe_on_install, but it's also gated by$kernelver = "$(uname -r)").
A common use case on clusters is to build an image inside a chroot and/or container. Often times the kernel on the build host differs from what was installed into the image (possibly even cross-architecture with binfmt_misc). In general there are 2 "styles" of RPM scriptlets.
Legacy packages call common.postinst
The
common.postinstscript has special handling to build for the correct kernel. A redacted example:This works well, although I believe
common.postinstis somewhat deprecated.Modern packages call dkms add/build/install
This fails to build the modules:
Proposed solution
Bring similar logic from
common.postinstinto dkms itself. If the headers for the running kernel is not found, and dkms is running in a chroot or container, try to detect the "best" kernel and build for that. Or should that happen unconditionally, even if not in a chroot?I have a code proposal I can use to create a pull request, but I wanted to get some feedback before submitting it. Thanks!