dkms.conf quoted the make binary: MAKE="'make' -C src/ all". dkms passes the
kernel it is building for by rewriting the leading "make" of that string into
"make -jN KERNELRELEASE=$kernelver" (dkms 3.2.1, line 1446) - an anchored
prefix substitution that the quotes defeat, so nothing was ever injected. The
Makefile then hardcoded /lib/modules/$(shell uname -r)/build and would have
ignored it in any case.
With AUTOINSTALL=yes the module was therefore always compiled against the
running kernel and installed into the tree of whichever kernel dkms was
building for. A dnf update that pulls in a new kernel builds against the old
one and drops the result in the new kernel's /extra, where it fails to load on
the next boot. Crossing RHEL 9.4 to 9.5 it would also compile the wrong side of
the vm_flags guard, which is how this was noticed.
The Makefile now takes KDIR, defaulting to the running kernel exactly as
before, and dkms.conf passes ${kernel_source_dir} - which dkms resolves for the
target kernel before sourcing the conf, and which honours --kernelsourcedir.
Dropping the quotes also lets dkms's -jN through, so the recursive invocations
become $(MAKE) to keep the jobserver.
Verified by building against a kernel other than the running one: the module
now comes out carrying the target kernel's vermagic.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PLMZgfMEdtPBZt1F2rNbRA
leonarski_fandClaude Opus 5
8db8267ff8