Suppose you install a new kernel (because it has been updated) on your system. Usually, you need to install new versions of 3rd kernel drivers through the club. For example: the nvidia drivers. In the club downloads, you will find the different versions of nvidia-kernel in http://rpms.mandrakeclub.com/rpms/mandrakeclub/comm/10.1/i586/NByName.html
However, this system has several disadvantages:
- one has to care about the kernel version he uses to install the correct version of the nvidia-kernel (nvidia-kernel-enterprise, smp ?)
- it is difficult to maintain. For example, when the kernel is updated (e.g from 2.6.8.1-10mdk to 2.6.8.1-12mdk), it may take some time before you get the new version of the nvidia-kernel package (e.g. from nvidia-kernel-2.6.8.1-10mdk to nvidia-kernel-2.6.8.1-12mdk)
So there is now a new way that solves both issues : dkms (Dynamic Kernel Module Support Framework). A dkms package is specific to a module, but not to the kernel version. It is installed as usual (using Rpmdrake or urpmi), then it transparently compiles and installs the driver for your running kernel. Advantage : only one package to select (ex: dkms-nvidia) whatever kernel you are running. And when you update your kernel, you just need to uninstall/reinstall the package so that it is updated to your new kernel ! No need to wait for a new version ! Also, dkms comes with a /usr/bin/dkms program that allows you to uninstall/reinstall drivers without uninstalling/reinstalling packages.
Note : a dkms package replaces the modulename-kernel package series. You should not install any modulename-kernel package, which is kernel version dependent. A dkms package is not kernel-version dependent and will work for any kernel minor version. However, it may need other binary packages (e.g. ati-3.14.1 or nvidia-6111 packages for dkms-ati and dkms-nvidia, respectively), but these requirements will be solved as dependencies by the software installer Rpmdrake or urpmi.
However, there is just one small thing to do when you want to install the dkms modules : you need to install the kernel-source-2.x or the kernel-source-stripped-2.x package corresponding to your kernel (with x = 4 or 6 for 2.4 or 2.6). This dependency is automatically solved by the software installer though, when you want to install dkms. Another requirement are compilation tools (gcc and libraries), that would also be installed as dependencies when dkms modules packages are installed. People who installed Mandrakelinux with "Development" tools have these requirements already.
Also, when you update your kernel, you also need to update your kernel source, i.e. the kernel-source-2.x package, which is always available and is also taken care of by the auto-updating with Rpmdrake/urpmi. Then, you need to update your dkms drivers for the new kernel, either by uninstalling/reinstalling the dkms-modulename packages (not very academic, but easy), either by using the /usr/sbin/dkms tool (see man dkms for information about how to use it). EDIT : according to this excellent paper http://linux.dell.com/dkms/dkms-ols2004.pdf you need to use dkms --match to reinstall the same modules that you used with your old kernel on the new kernel.
A clarification : you don't compile a kernel at all ! dkms automatically compiles the specific driver, and it needs the kernel-source package to have the headers of the kernel (it is called compiling against the source of the kernel.) No technical skill about compilation is actually needed, basically it is just a package install operation. It is why compilation of a driver is specific to a kernel version. But the kernel is not compiled or reinstalled, it is untouched. Drivers are installed in 3rd party directory in the kernel modules directory.
As of today, there are dkms packages for:
dkms-aic79xx for the Adaptec AIC-7901 on-board controller
dkms-ati for ATI 3D graphical cards
dkms-ipw2100 for Centrino ipw2100 (in testing)
dkms-ipw2200 for Centrino ipw2200 (Buchan Milne's repository, see below)
dkms-ivtv for iTVC15/16 and CX23415/16 driver. These chips are commonly found on Hauppauge's WinTV PVR-250 and PVR-350 TV capture cards.
dkms-lazyfs Lazyfs is a kernel module needed by the Zero Install system.
dkms-nvidia (club commercial only) for nVidia 3D graphical cards
dkms-slmodem (10.1 Official CD/DVD, club)
dkms-zaptel for the Zapata Telephony Interface
rt2500-dkms for the Ralink RT2500 802.11g chipset
dkms-fcusb2
dkms-fcdslusba
dkms-fcdslsl
dkms-fcpci
dkms-fxusb
dkms-hcfpcimodem
dkms-madwifi
dkms-unicorn
dkms-pwc Logitech and Philips webcams (Buchan Milne's repository, see below)
and more will be made available regularly.
Note 1: a lot of dkms packages are available on the Powerpack CD3, in the /media/dkms directory. 12/01/05: They have also been added to the club media.
Note 3: dkms packages are in process of renaming from xxx-dkms to dkms-xxx, especially in cooker (the development version of Mandrakelinux, that leads to the next stable release). Just make a search in Rpmdrake or using urpmq -y dkms to see which dkms kernels are available in your media and their names. Another on-line search engine is available there: http://rpms.mandrakeclub.com/
To summarise:
dkms-modulename replaces the set of modulename-kernel-xx packages that are specific to one kernel. There is one dkms package per module, ex: dkms-nvidia, dkms-ati, dkms-slmodem, etc... Other dependencies may be required, exactly like for modulename-kernel-xx (e.g. nvidia-kernel-xx also leads to install the binary proprietary nvidia-6111 driver package, so dkms-nvidia does. But don't worry, dependencies are automatically handled by the software installer, Rpmdrake or urpmi).
For illustration, just compare on CD3 of Powerpack 10.1 the content of /Drivers and /media/dkms : these are the dkms equivalents.
If you don't want or cannot compile on your machine, stick to the classic modulename-kernel-xx set packages for 3rd party drivers. If you have the tools for compilation, try dkms packages (but note you don't need to have compilation skills, this is handled automatically during the package installation procedure, nor do have to compile the kernel itself).
Disadvantages:
- The kernel-source package corresponding to your kernel (2.6 or 2.4) has to be installed. It is a big package, needs space, but there is a lightweight version of this package, kernel-source-stripped-xx that contains everything you need to compile 3rd party drivers.
- Development tools must be installed, like the compiler gcc. Not very difficult with Rpmdrake
Advantages: they are huge:
- no risk of error: there's only one package dkms-modulename per module to install, whatever kernel version is run
- in case of kernel update/change, no need to wait for the new modulename-kernel-xxx: reboot with new kernel, install of new kernel-source, reinstall the same dkms-modulename and it simply works !
- it also works for "housemade" kernels.
Many thanks to all the developers who maintain the dkms packages.
Last edited by zeb on Mon Jan 24, 2005 2:43 pm; edited 35 times in total
What mirror do I find these On? I'm looking for the dkms-ivtv for a pvr-250 card and I can't find it.
I think the IVTV supplies the drivers. Just have to install the kernel for IVTV using DKMS.
Quote:
dkms-ivtv for iTVC15/16 and CX23415/16 driver. These chips are commonly found
on Hauppauge's WinTV PVR-250 and PVR-350 TV capture cards.
I just hope it is as easy as it sounds. I am not good at compiling kernels. And I don't want to trash my system. Wish they had a newbie style step by step of how to install the dkms-ivtv with keystroke by keystroke steps. (Terrible isn't it....to be so unlearned in linux and trying to do all these things....one of these days maybe I will have the time and location to be able to attend a linux college class)
What mirror do I find these On? I'm looking for the dkms-ivtv for a pvr-250 card and I can't find it.
Some of them may be found on :
Powerpacks CDs/DVD (soon they will be available through the club)
or Cooker mirrors, because they are still in development (but will be added to 10.2 final). However, since dkms makes the package kernel-version independent, I guess cooker packages could be used on 10.1.
An advice : install dkms packages in console, as root, using urpmi. This way, you will get console output and will check if everything works allright (otherwise, you may see error messages, but this should not happend hopefully; please report problems).
Last edited by zeb on Wed Jan 12, 2005 9:00 am; edited 1 time in total
I just hope it is as easy as it sounds. I am not good at compiling kernels. And I don't want to trash my system.
A clarification : you don't compile a kernel at all ! dkms compiles the specific driver, and it needs a kernel-source package to have the headers of the kernel. It is why compilation of a driver is specific to a kernel version. But the kernel is not compiled or reinstalled, it is untouched. Drivers are installed in 3rd party directory in the kernel modules directory.
And when you update your kernel, you just need to uninstall/reinstall the package so that it is updated to your new kernel !
Will you lose the old kernel modules?
Hi, they are backed up. See man dkms, I reproduce the part concerning your question :
Code:
ORIGINAL MODULES
During the first install of a module for a <kernelversion>, dkms will
search /lib/modules/<kernelversion> for a pre-existing module of the
same name. If one is found, it will automatically be saved as an "orig-
inal_module" so that if the newer module is later removed, dkms will
put the original module back in its place. Currently, DKMS searches
for these original modules with first preference going to modules
located in /lib/modules/<kernelversion>/updates/ followed by $DEST_MOD-
ULE_LOCATION (as specified in dkms.conf ). If one cannot be found in
either location, a find will be used to locate one for that kernel. If
none are found, then during a later uninstall, your kernel will not
have that module replaced.
If more than one is found, then the first one located (by preference
indicated above) will be considered the "original_module". As well,
all copies of the same-named module will be removed from your kernel
tree and placed into /var/lib/dkms/<module>/original_module/$ker-
nelver/collisions so that they can be *manually* accessible later. DKMS
will never actually do anything with the modules found underneath the
/collisions directory, and they will be stored there until you manually
delete them.
- Thanks to Frederic Lepied, the dkms packages that are present on the Powerpack CDs/DVD are now uploaded to the club downloads. They should be available soon.
The only dkms packages I found were the ones for Nvidia, ipw, and a few like that. I have the dkms-Nvidia package already installed.
Quote:
Robert_Courtright wrote:
What mirror do I find these On? I'm looking for the dkms-ivtv for a pvr-250 card and I can't find it.
Some of them may be found on :
Powerpacks CDs/DVD (soon they will be available through the club)
or Cooker mirrors, because they are still in development (but will be added to 10.2 final). However, since dkms makes the package kernel-version independent, I guess cooker packages could be used on 10.1.
Are the ivtv packages for the pvr-250 going to be dkms-ivtv or something like this? I still don't understand the "how-to" on installing the pvr-250 packages. What I am asking is -- Now that I have 'already' installed the dkms-Nvidia package does that mean that there is no further need to install any dkms packages and now I just install the ivtv packages from thac or some other website or do we have to find and install a **dkms-ivtv** package to get all the benefits of the dkms??
The only dkms packages I found were the ones for Nvidia, ipw, and a few like that. I have the dkms-Nvidia package already installed.
You are wright for the club (dkms-slmodem has also been uploaded), I will ask Frederic to upload the rest.
However, dkms packages can be found on the 3rd CD of Powerpack isos. But not dkms-ivtv, which is still development, but can be freely found on cooker mirrors (see below).
Quote:
Are the ivtv packages for the pvr-250 going to be dkms-ivtv or something like this? I still don't understand the "how-to" on installing the pvr-250 packages.
dkms is generic, it is the way how these modules (drivers) are installed. Now you need one dkms package for each module.
If you have an nvidia card, and want the 3D proprietary drivers, you install dkms-nvidia. It will also install, as dependencies, nvidia-6111 package which contains the nvidia binaries (dkms-nvidia replaces all the set of nvidia-kernel-xxx packages).
Now, dkms-ivtv is another dkms module, for ivtv cards.
Each dkms-modulename is specific, and you install several dkms packages all along, each one for each driver you need. Exactly like you did before with nvidia, slmodem, and so on.
A clarification : you don't compile a kernel at all ! dkms compiles the specific driver, and it needs a kernel-source package to have the headers of the kernel. It is why compilation of a driver is specific to a kernel version. But the kernel is not compiled or reinstalled, it is untouched. Drivers are installed in 3rd party directory in the kernel modules directory.
Does this mean that we must have developer tools installed on every machine? I mean on
my laptop, i don't use to develop, i don't have gcc installed. Now every time i update the
kernel from MandrakeUpdate i have to rebuild my drivers by myself, instead of get them from club :?:
Does this mean that we must have developer tools installed on every machine? I mean on
my laptop, i don't use to develop, i don't have gcc installed. Now every time i update the
kernel from MandrakeUpdate i have to rebuild my drivers by myself, instead of get them from club :?:
Oh yes, I forgot this. I guess depedndencies for the compiler (gcc) are solved when one tries to install a dkms module. I shall update the doc then.
But don't worry. As we discussed on cooker mailing-list, Buchan supported the idea that both dkms and kernel-specific modules should be available, for people who do not want or cannot install source and compilation tools.
Oh yes, I forgot this. I guess depedndencies for the compiler (gcc) are solved when one tries to install a dkms module. I shall update the doc then.
But don't worry. As we discussed on cooker mailing-list, Buchan supported the idea that both dkms and kernel-specific modules should be available, for people who do not want or cannot install source and compilation tools.
Zeb
Anyway I don't mind but as you said it was a clarification, so has to be known
Thanks for the info - i did not know about dkms. I'll keep it in mind for the future.
...
... the title, way up there, should be amended to
For 10.1 and greater releases
or 10.2 BETA1 which is available at your favorite mirror.
[EDIT]
The path to get there(dkms) from 10.0 is not so easy. I am working on it.
[p2]
Whoa! that was fun! No, really! I love breaking stuff and putting it back togther again - I must, I keep doing it.
I cannot take all the credit tho' since it is the dkms packages that broke it - i just fixed what broke.
I am not sure what caused it... might be that colorgcc interfered with the build. The nvidia installer choked with a cyclic redundancy and did not believe I had the correct gcc installed; the dkms build did the same. Actually it did it first but there were a bunch of other problems(boy, is that dkms dumb! it is dumber than me about where files are on MDK...) so I did not connect the colorgcc w/ the problem until after I had given up and ... while running the nividia-installer. I rpm -e'd the colorgcc and nividia did its thing w/out complaining.
The short of it is that after upgrading ~90MB worth of files to get dkms installed, I logged out to restart X and X died: ' API invalid ' because the kernel module for 6111 could not load & of course "screens not found" stuff. Actually, the API problem was because the nVidia driver 6629 loaded but it was being given the 6111 module... anyway, it did not work & dkms had not done as promised.
The so-called kernel module was not available... and it absolutely refused to ' build ' anything. -Kept dying on make of "Makefile" (which did not exist).
The distressing part is that the dkms has NO knowledge of where files are located on the MDK distro. It did not even know that the config file used to build the kernels is in the /boot dir... even I know that!
I certainly do like the idea though and hope that BM and, iguess, you can make it do as promised.
...
If somebody else wants to do it on 10.0, briefly, upgrade the MCC by selecting the '' drakconf '' from the 10.1 main http/ftp site using MCC. About fifty files(I'm guessing) or 85MB of files(i rem that) will have to be installed... including the newer gtk+-2(!). If MCC did it's job correctly, all the dependencies are satisfied and dkms can be installed. I have not tested everything but so far only gkrellm was acting up & once I upgraded it, it returned to normal. _________________ rj
Linux is about taking control of your own life, not asking others to take control of things for you.
Linux User 212962;
Get Folding now with MDK Team # 12501: http://vspx27.stanford.edu/cgi-bin/main.py?qtype=teampage&teamnum=12501
rjcooks : you are right, I shall change my title.
I always wondered how it would handle a compilation problem, now we know... But in your case, the problem lies with the nvidia driver apparently, and maybe gcc.
What would be good would be to write a page about how to restore the graphical desktop after any bad manipulation.
I always wondered how it would handle a compilation problem, now we know... But in your case, the problem lies with the nvidia driver apparently, and maybe gcc.
I am not sure if colorgcc was the cause. BUT I am sure that colorgcc usage has a bug in it. IIRC, it has been there for a while because the symlinks are't setup correctly. I had it running smooth as silk back with 9.0 but have not had the time to investigate if it was still 'broke' -well, now I know. I'll have to add that to the bug-slapper list since it has been around for so long... at least here, it has.
I'm pretty sure it was not nvidia: nvidia does not have a mechanism to keep some other program from overwriting or moving/renaming the files.
I thought about the incident a bit and the bottom line, for me, is that dkms should not change anything when it gets installed. Since it can completely bork a system, the end user needs to be WARNED and, ithink, provided the steps that dkms is going to do before it does them. Of particular importance is that the dkms.conf file is checked for correct usage. I could not "build" because it could not make Makefile ... not sure why.
As I said before, the defaults were all wrong, at least according to what dkms reported and the man page indicated and the results I got when I used the options like kernelsourcedir and config. ... After i get a 'lab' setup, I'll test again and report to bugzilla... later.
Quote:
What would be good would be to write a page about how to restore the graphical desktop after any bad manipulation.
man is your friend.
Actually I got out of it easily because I was prepared for it. Years of MDK & X taught me good... I make text docs that I can reference easily and take advantage of the MDK way of providing multiple VTs for us. You might recall that XFree often "cannot find font fixed" in the past. For a newbie, that's gibberish so I'll post something for that. However, unless it gets committed to mem, it won't help a newbie much when the X system goes down because navigating this forum in lynx is pretty wild...
What would be really good is a text only section for reference docs at MDK so that someone can easily scan a list of links to docs that will get them out of trouble... AYA project.
As for dkms, I am not quite ready for that experience again. I need to setup my network and do it on another machine. I'll get to it because I want to make 10.2 one heck of a lot better than 10.0. I guess my 10.0 PP purchase was a donation... , which is ok but I had hoped to not be out on the bleedin' edge. (security...)
You know the saying: If you want to be on the cutting edge, you can expect to get cut. _________________ rj
Linux is about taking control of your own life, not asking others to take control of things for you.
Linux User 212962;
Get Folding now with MDK Team # 12501: http://vspx27.stanford.edu/cgi-bin/main.py?qtype=teampage&teamnum=12501
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Help
Search
Log in 
I'll have to add that to the bug-slapper list since it has been around for so long... at least here, it has.