dkms vs later kernels

gene heskett gheskett at
Wed Oct 13 13:50:37 CDT 2010

Greetings all;

First post to this list.

I am an older (76), fairly technically inclined man, involved with the 
dirty job of keep a television station on the air since back in the 60's.  
I generally troubleshoot to the bad part level. I can code just well enough 
to be dangerous. ;-)

Running pclos-2010.7, 32 bit on a quad core phenom with 4G of ram & a bit 
over 4 TB of drives in this box, each drive generally dedicated to a given 
install, with pclos installed on /dev/sda.

I also stay current with the stable kernels, having years ago cobbled up 
some scripts that make building a new, similarly configured kernel a 2 
script process.  Currently running built for 32 bit smp stuff.

Recently dkms, when launched by the /etc/init.d/mandrake_everytime (pclos 
is largely based on mandriva) during the boot, has been returning an error 
5 for all attempts to build the various modules which include the ati 
(fglrx) and nvidia (256.13.whatever is the latest version) and 
vboxadditions (which I haven't found a use for just yet)

The error 5, when googled for, says to check the 
/var/lib/dkms/whatever/build/make.log file for the full error.  But,,, that 
log file doesn't exist after the failure(s). :(

This obviously means I am stuck on the vesa driver for a moderately fancy 
nvidia video card.  So I have basic video only.

Recent kernel configs no longer have an option that creates the 
/lib/modules/`uname -r`/kernel/drivers/char/drm directory tree, even if I 
build the drm for an ati card.

My kernel build and install script does do a "make headers_install" so the 
headers are there for a kernel-$VER.

Is this something that I can fix in dkms.conf, or is it deeper than that?

My present dkms.conf as it exists in the nvidia-current linked tree:

MAKE[0]="make SYSSRC=${kernel_source_dir} module"
CLEAN="make -f Makefile.kbuild clean"

As a side note, the dkms system (here at least, thinks all the modules are 
installed on a same kernel rebuild, but my scripts keep an .old version of 
everything for one generation, which I have tried to hack around with this 
script, called at the end of my installer script, and which appears to work 
just fine, but that doesn't keep dkms from thinking the module has been 
installed.  This script:

#		makeit-helper for dkms blobs					#
#	By Gene Heskett, with help from Jon LaBadie			#
#			August 25, 2010						#
#												#
# do housekeeping during a kernel build and install by makeit	#
# needs 2 arguments passed from the makeit script			#
# first, the makeit scripts $VER (kernel version)				#
# second, the operating tree it is to search, usually:			#
# /var/lib/dkms										#
# check input vars
if [ -z "$1" ]
	echo "Usage: `basename $0` version path"
	exit $BADARGS
if [ -z "$2" ]
	echo "Usage: `basename $0` version path"
	exit $BADARGS
echo "third argument is "$3
# prints a 1 if I pass 1 as third argument
if [ -z "$3" ]
# we have possibly valid input, we can echo to check
#echo $VER
#echo $POTH
cd $POTH
/bin/find -type d -name $VER >dirlist
# now have file 'dirlist' in the $POTH dir, cat for content
# cat dirlist
#echo $dirlist 
#cat dirlist
#cat "$dirlist"

read dirname <$dirlist
until [ "$dirname" = "" ]
	read dirname
	if [ "$dirname" != "" ]
		echo "rm -fR "$dirname"-old"
		if [ "$ENABLE" ]
			echo "actually doing the above"
			# first, get rid of error if it doesn't exist
			touch $dirname-old
			# now remove it w/o error
			rm -fR $dirname"-old"
		echo "mv "$dirname $dirname"-old"
		if [ "$ENABLE" ]
			echo "actually doing the above"
			mv $dirname $dirname"-old"
		sleep 1
done <"$dirlist"

#echo $count
exit 0

Which essentially just renames the present  module$version trees in 
/var/lib/dkms to module$version.old, but does not create the new ones, 
leaving that to dkms.

Any ideas to try here?

Thanks a bunch.

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
I like your SNOOPY POSTER!!

More information about the DKMS-devel mailing list