Ubuntu
dkms package

  1. Bug #438393
  2. Comment #6

Comment 6 for bug 438393

Revision history for this message
Michael B. Trausch (mtrausch) wrote :

The su nobody command also prohibits builds from working when using a custom kernel:

mbt@zest:/var/lib/dkms/nvidia/185.18.36/build$ sudo su nobody -c "make KERNELRELEASE=2.6.31.3-bfs303 module KERNDIR=/lib/modules/2.6.31.3-bfs303 IGNORE_XEN_PRESENCE=1 IGNORE_CC_MISMATCH=1 SYSSRC=/lib/modules/2.6.31.3-bfs303/build"
If you are using a Linux 2.4 kernel, please make sure
you either have configured kernel sources matching your
kernel or the correct set of kernel headers installed
on your system.

If you are using a Linux 2.6 kernel, please make sure
you have configured kernel sources matching your kernel
installed on your system. If you specified a separate
output directory using either the "KBUILD_OUTPUT" or
the "O" KBUILD parameter, make sure to specify this
directory with the SYSOUT environment variable or with
the equivalent nvidia-installer command line option.

Depending on where and how the kernel sources (or the
kernel headers) were installed, you may need to specify
their location with the SYSSRC environment variable or
the equivalent nvidia-installer command line option.

*** Unable to determine the target kernel version. ***

make: *** [select_makefile] Error 1
mbt@zest:/var/lib/dkms/nvidia/185.18.36/build$

vs:

mbt@zest:/var/lib/dkms/nvidia/185.18.36/build$ sudo make KERNELRELEASE=2.6.31.3-bfs303 module KERNDIR=/lib/modules/2.6.31.3-bfs303 IGNORE_XEN_PRESENCE=1 IGNORE_CC_MISMATCH=1 SYSSRC=/lib/modules/2.6.31.3-bfs303/build
NVIDIA: calling KBUILD...
make CC=cc KBUILD_VERBOSE=1 -C /lib/modules/2.6.31.3-bfs303/build SUBDIRS= modules
make -f /home/mbt/Projects/git/linux-2.6.31.y/Makefile silentoldconfig
make -f scripts/Makefile.build obj=scripts/basic
  gcc -Wp,-MD,scripts/basic/.fixdep.d -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/basic/fixdep scripts/basic/fixdep.c
...

Using a different account for building dkms modules is understandable, but if it's going to do that, it should do sanity checking first and ensure that it can access things that way. If it cannot it should either not use su at all, or it should copy the kernel source symlink target to a location it can use, and build against that tree, then remove the tree when its done.