DKMS module fails to build if CC env-var set but not OK (=> "sudo -H"?)

[Pauli Virtanen]

Binary package hint: dkms

When the CC environment variable is set, dkms may fail to build. In my case, apparently because the CC is not readable to user "nobody" (it points to a ccache-using script).

DKMS should reset environment variables such as CC or CXX. This is important for Ubuntu, where stuff is usually run with sudo, which does not reset env-vars.

This bug causes for example Nvidia's display driver updates to always fail, which will be noticed only on next boot (when gdm enters an infinite respawn loop, cf. #431166).

Also, why is the package upgrade not marked as failed if dkms fails to build the module?

Output on failed package upgrade:

---------------
Configuring: nvidia-185-kernel-source (185.18.36-0ubuntu3) ...
Removing all DKMS Modules
Done.
Adding Module to DKMS build system
driver version= 185.18.36
Doing initial module build

Error! Bad return status for module build on kernel: 2.6.31-11-generic (i686)
Consult the make.log in the build directory
/var/lib/dkms/nvidia/185.18.36/build/ for more information.
Installing initial module

Error! Could not locate nvidia.ko for module nvidia in the DKMS tree.
You must run a dkms build for kernel 2.6.31-11-generic (i686) first.
Done.
---------------

The make.log reports:
---------------
DKMS make.log for nvidia-185.18.36 for kernel 2.6.31-11-generic (i686)
ti 29.9.2009 00.03.29 +0300

The C compiler '/home/pauli/bin/gcc-cached' does not appear to be able to
create executables. Please make sure you have
your Linux distribution's libc development package
installed and that '/home/pauli/bin/gcc-cached' is a valid C compiler
name.

*** Failed CC sanity check. Bailing out! ***

make: *** [select_makefile] Virhe 1
---------------

ProblemType: Bug
Architecture: i386
Date: Tue Sep 29 00:07:11 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: dkms 2.1.0.1-0ubuntu1
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=fi_FI.UTF-8
 PATH=(custom, no user)
 LANG=fi_FI.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: dkms
Uname: Linux 2.6.31-11-generic i686

[Mario Limonciello (superm1)]

I'm a bit perplexed how you hit this. By default sudo *does not* pass the environment variables around.

supermario@mlimonciello:~$ export CC=blah
supermario@mlimonciello:~$ export | grep CC
declare -x CC="blah"
supermario@mlimonciello:~$ sudo -s
root@mlimonciello:~# export | grep CC
root@mlimonciello:~#

[Pauli Virtanen (pauli-virtanen)]

It's set in $HOME/.bashrc (mine, not root's) which causes the env vars to appear also for root.

[Daniel Hahler (blueyed)]

dkms should use "sudo -H" then probably (to use the target users $HOME).

[Pauli Virtanen (pauli-virtanen)]

Possibly -- dkms is currently just su'ing to nobody, which doesn't reset any env vars. The following seems to work, though I'm not sure if something can fail for some modules as nobody's $HOME does not exist:

--- dkms.orig 2009-10-14 22:32:24.882924512 +0300
+++ dkms 2009-10-14 22:41:40.002269942 +0300
@@ -1522,8 +1522,8 @@
     local the_make_command=`echo $make_command | sed "s/^make/make KERNELRELEASE=${kernelver_array[0]}/"`

     #if we're root, try to run as a user instead
- if [ "$USER" = "root" ] && getent passwd nobody 1>/dev/null && su nobody -c "/bin/true" 1>/dev/null; then
- the_make_command="su nobody -c \"$the_make_command\""
+ if [ "$USER" = "root" ] && getent passwd nobody 1>/dev/null && sudo -H -u nobody /bin/true 1>/dev/null; then
+ the_make_command="sudo -H -u nobody /bin/sh -c \"$the_make_command\""
         chmod +x $dkms_tree/$module/$module_version/build
         chown -R nobody $dkms_tree/$module/$module_version/build
     fi

[Michael B. Trausch (mtrausch)]

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.

[Mario Limonciello (superm1)]

http://linux.dell.com/git/?p=dkms.git;a=commit;h=ff363e508016da5912566ee2138200d2636835ed

[Launchpad Janitor (janitor)]

This bug was fixed in the package dkms - 2.1.1.0-0ubuntu1

---------------
dkms (2.1.1.0-0ubuntu1) lucid; urgency=low

  [ Mario Limonciello ]
  * New upstream version
  * dkms_autoinstall: Minor logic cleanups from submitted patches.
  * dkms_autoinstall: Run under dash since dkms.conf isn't sourced anymore.
  * dkms_autoinstall: Whitespace cleanup.
  * Convert DKMS to an upstart script that starts up before GDM or KDM can
    start. This ensures that drivers are built before X tries to start.
    (LP: #453365)
  * dkms_autoinstall: Rather than having if/else clauses all over the script,
    stub out any functions that aren't provided on Debian/Ubuntu when
    /etc/debian_version isn't present.
  * dkms_autoinstall: Exit immediately if this script is present but DKMS
    isn't anymore rather than sourcing functions and then exiting.
  * kernel_postinst.d_dkms: Launch the upstart script instead. In the process
    all output will be going to /var/log/dkms_autoinstaller (LP: #292606)
  * dkms_autoinstall: Don't ever output to stdout, even with kernel parameters.
  * dkms_autoinstall: Don't log the situation that we already have everything
    installed that needs to be.
  * dkms_autoinstall: Rather than logging to /var/log/dkms_autoinstaller,
    use logger to log to syslog during build and install.
  * dkms_autoinstall: Clean up the method to get arch. These hacks shouldn't
    be necessary. If you have problems with them gone, file a bug and we'll
    fix them more cleanly.
  * dkms_autoinstall: Notate the kernel we are building a module against
    when building it.
  * debian/rules: Don't attempt to stop DKMS on upgrades. It's a task, not
    a daemon, so stop wouldn't do anything.
  * Makefile: Install the old initscript to /usr/lib so that different distros
    can migrate to upstart at their leisure.
  * Makefile: Move any debian specific calls into the Makefile.
  * dkms: Revert the code that runs DKMS as the user "nobody".
    - It's causing problems with people with nonstandard PAM configs because it
      uses "su". (LP: #484725)
    - Also people have reported that nothing should be owned by 'nobody' per
      Debian & Ubuntu policy. This could have been fixed by creating a DKMS
      user, but that still wouldn't solve the problems with using 'su'.
  * dkms: Emit built-module MODULE=foo if initctl is available on the system
    after done building a module.
  * Add a special apport package-hook for when package builds fail to try
    to report them against the package providing that DKMS package.
    (LP: #484871)

  [ Alberto Milone ]
  * dkms_common.postinst: try to build the module for the most recent
    kernel in addition to building it for the current kernel (LP: #474917).

  [ Steve Langasek ]
  * dkms_autoinstall: optimize with a single find call instead of multiple
    loops with ls. (LP: 3484386)
  * dkms_autoinstall: drop localization of the usage message - this is
    inconsistent with all other init scripts on the system.

  [ Pauli Virtanen ]
  * Remove dependence from environment's umask and certain environment
    variables. (LP: #438393, #436039)

  [ Giuseppe Iuculano ]
  * dkms_autoinstall: Correct the prov...