dkms vs later kernels

Matt Domsch Matt_Domsch at dell.com
Mon Oct 18 14:31:00 CDT 2010


On Wed, Oct 13, 2010 at 02:50:37PM -0400, gene heskett wrote:
> 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 2.6.35.7 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?

Can you run dkms manually and see what it says then?  It may say the
same thing, with no log file, but that would be very odd.  There's
also 'bash -x dkms ...'

DKMS should create the kernel/drivers/char/drm directory if it needs
to place something in there.  You're failing at build time it seems,
not install time.


> 
> My present dkms.conf as it exists in the nvidia-current linked tree:
> 
> PACKAGE_NAME="nvidia-current"
> PACKAGE_VERSION="256.53-1pclos2010"
> BUILT_MODULE_NAME[0]="nvidia"
> DEST_MODULE_LOCATION[0]="/kernel/drivers/char/drm"
> DEST_MODULE_NAME[0]="nvidia-current"
> MAKE[0]="make SYSSRC=${kernel_source_dir} module"
> CLEAN="make -f Makefile.kbuild clean"
> AUTOINSTALL="yes"
> 
> 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.

DKMS simply is looking at the file system, comparing what is installed
in /lib/modules/ with what is in any of its trees, including for you,
your .old trees.  Why not leave the modules in built but not installed
state?  And you shouldn't need a .old directory if the modules are
increasing their version numbers as you would expect them to do.
It's perfectly valid to have the same module, but different versions
thereof, built, but not installed, simultaneously.  Only one can be
installed (for obvious reasons).

Thanks,
Matt

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO



More information about the DKMS-devel mailing list