On Wed, 2016-04-06 at 20:40 -0700, Kevin Locke wrote: > Package: nvidia-kernel-source > Version: 352.79-5 > Severity: normal > > Dear Maintainer, > > Starting in version 352.79-2 I am unable to build the nvidia kernel > module for custom kernels using make-kpkg (part of the kernel-package > package). I have confirmed that the issue is present in both 352.79-5 > and 355.11-2. The error which occurs is: > > $ make-kpkg -j4 --rootcmd fakeroot --append_to_version +kevinoid1 --revision > 4.5+1 --added_modules nvidia-kernel modules_image > [...] > make[2]: Entering directory '/usr/src/modules/nvidia-kernel' > /usr/bin/make KBUILD_VERBOSE=1 -C /lib/modules/4.5.0+kevinoid1/build > M=/usr/src/modules/nvidia-kernel ARCH=x86_64 > NV_KERNEL_SOURCES=/lib/modules/4.5.0+kevinoid1/build > NV_KERNEL_OUTPUT=/lib/modules/4.5.0+kevinoid1/build NV_KERNEL_MODULES="nvidia > nvidia-uvm" INSTALL_MOD_DIR=kernel/drivers/video Q= modules > make[3]: Entering directory '/usr/src/modules/nvidia-kernel' > make[3]: *** /lib/modules/4.5.0+kevinoid1/build: No such file or directory. > Stop. > make[3]: Leaving directory '/usr/src/modules/nvidia-kernel' > Makefile:81: recipe for target 'modules' failed > make[2]: *** [modules] Error 2 > > I have attached both a successful build log (with version 352.79-1) and > an unsuccessful one (with version 352.79-2) using the same command as > above. > > I believe this is due to debian/rules not passing KSRC (/usr/src/linux > in my case) to the nVidia Makefile, which attempts to deduce it from the > version information. This fails if the kernel is not yet installed, > which is always the case when building the module with the kernel using > make-kpkg. I think this behavior was introduced in r6121.[1]
Hello Kevin,
Sorry for the problem you are facing, it's a corner case that I don't
usually test.
I didn't have time to fully reproduce your environment, but could you
please try with the attached patch (for the debian/rules in the 352.79-5
kernel-source)? It should allow one to pass an arbitrary KSRC directory
if the one derived from the version does not exist, which allows the
current behaviour to continue. I'll try and find the time to fully test
it myself as well in the following days.
Andreas,
Was there any specific reason to prefer letting the module derive the
kernel source path from the version?
Kind regards,
Luca Boccassi
--- debian/rules
+++ debian/rules
@@ -22,7 +22,14 @@
ifndef KPKG_DEST_DIR
KPKG_DEST_DIR = ..
endif
+ifndef KVERS
KVERS := $(shell perl debian/kernel-version $(KSRC))
+endif
+ifeq ($(wildcard /lib/modules/$(KVERS)/build),)
+ SYSSRC=SYSSRC=$(KSRC)
+else
+ SYSSRC=
+endif
export KVERS
export KPKG_DEST_DIR
@@ -42,8 +49,8 @@
build-stamp: configure-stamp
dh_prep
dh_quilt_patch
- unset ARCH; $(MAKE) module KERNEL_UNAME=$(KVERS)
- unset ARCH; $(MAKE) -C uvm module KERNEL_UNAME=$(KVERS)
KBUILD_EXTMOD=$(CURDIR)/uvm
+ unset ARCH; $(MAKE) module KERNEL_UNAME=$(KVERS) $(SYSSRC)
+ unset ARCH; $(MAKE) -C uvm module KERNEL_UNAME=$(KVERS) $(SYSSRC)
KBUILD_EXTMOD=$(CURDIR)/uvm
test "nvidia-current" = "nvidia" || mv nvidia.ko nvidia-current.ko
test "nvidia-current" = "nvidia" || mv uvm/nvidia-uvm.ko
uvm/nvidia-current-uvm.ko
touch $@
@@ -76,8 +83,8 @@
test -f debian/control || cp debian/control.template debian/control
dh_testdir
dh_testroot
- $(MAKE) clean KERNEL_UNAME=$(KVERS) $(KPKG_EXTRAV_ARG)
- $(MAKE) -C uvm clean KERNEL_UNAME=$(KVERS) $(KPKG_EXTRAV_ARG)
+ $(MAKE) clean KERNEL_UNAME=$(KVERS) $(SYSSRC) $(KPKG_EXTRAV_ARG)
+ $(MAKE) -C uvm clean KERNEL_UNAME=$(KVERS) $(SYSSRC) $(KPKG_EXTRAV_ARG)
dh_quilt_unpatch || quilt --quiltrc /dev/null pop -af
dh_clean debian/control debian/install
signature.asc
Description: This is a digitally signed message part
