leonarski_fandClaude Opus 5
8db8267ff8
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
11 lines
252 B
Plaintext
11 lines
252 B
Plaintext
PACKAGE_NAME=jfjoch
|
|
PACKAGE_VERSION=1.0.0-rc.163
|
|
|
|
DEST_MODULE_LOCATION=/extra
|
|
BUILT_MODULE_NAME=jfjoch
|
|
BUILT_MODULE_LOCATION=src/
|
|
|
|
MAKE="make -C src/ KDIR=${kernel_source_dir} all"
|
|
CLEAN="make -C src/ KDIR=${kernel_source_dir} clean"
|
|
AUTOINSTALL="yes"
|