Whilst this has been done for Mandriva 2006, it can also apply for previous versions. There's a kernel faq in the faq section of this board, however, I decided to write this as a quick and easy way to upgrade without actually having to do much.

Normal kernel versions for Mandriva 2006 are 2.6.12.12mdk standard, up to 2.6.12.17mdk as of present. Some people have wondered what to do if you need to get something working/compiled that requires a later kernel. I also heard people mention problems trying to do manual kernel upgrades on Mandrake/Mandriva due to the way they are normally set up. So I figured, I'll give it a go and see if it's really that bad. As it happens, no, it worked a treat

First, I downloaded 2.6.15.6 from kernel.org (this is the latest as of todays date). Download the bz2, it's 10MB smaller than the GZ. This was saved to my ~/Download directory. In my example, this refers to /home/ian/Download. First off, you need to extract it and update the symlink, so:



Now, you've unpacked it, this is where we issue a few commands and then sit back and wait for about 30 minutes or so. Kernel compilation can take some time, especially if your machine is low spec. Mandriva's kernels are mostly modular, and for this, we're going to keep it the same. First, check that you can see files in your /boot directory. Specifically, the /boot/config file which is a symlink to your current kernel config file. If you can see this, then this makes it real easy. Why it makes it easy is that your current config file will be read by the kernel, therefore using all the settings from your existing Mandriva kernel. That way you don't have to worry about building a kernel that misses something and causes problems later. So, the next steps we do are:

Please note, if you want the Mandriva Bootsplash, make sure you check the Bootsplash section towards the bottom of this post. If you continue as below, the kernel will be compiled without bootsplash support.



and that's it, your kernel config is exactly the same as your current 2.6.12 Mandriva kernel.

Compiling the kernel

Now, we need to compile it. I normally just add it all on one line, so that you just leave it go and it'll finish and complete automatically for you. Below, I've listed the options you can do in 3 stages, and then all in one:



this means you have to keep checking after each stage. However, this one command will do it all for you:



The first part compiles the kernel and modules. The second part installs the modules and the third part copies the kernel into place, creates the initrd image that Mandriva requires and copies the system.map, kernel.h and config files into the /boot directory. The contents of my directory is listed as follows:



I didn't bother to update my symlinks for config, etc, etc. I could do, but for now, I've installed it as it. The last command also modified my lilo configuration and created an entry called "26156". So my main entries allow me to boot my standard Mandriva kernel, and the last one allows me to boot my newly created kernel. Updating your symlinks is only required if you have implicitly pointed your lilo/grub configuration to look at the symlinks instead of the actual kernel version itself. My new kernel is functioning correctly without having to do this.

Mandriva Bootsplash

The Mandriva bootsplash will no longer be present, but this is only a minor thing. A patch can be applied to get it back. Therefore, you need to change the steps from "make menuconfig". First, you need to download from here:

ftp://ftp.openbios.org/pub/bootsplash/ker...1.6-2.6.15.diff (info provided in post #8 below by mandrivauser ceco)

The steps to enable are as follows:



exit and choose save option, then continue using the compile steps as shown above. If using later kernel version in the future, then check for a later version of the bootsplash here: http://www.bootsplash.org/kernel.html

Additional posts below list success stories as well as problems encountered and how to resolve them. Please read all the below so that you can make sure your kernel migration is a success.

Thanks!

I wouldn't compile my kernel as root, it doesn't sound like a good idea. Maybe in a fakeroot environment, but why not as plain user?

Plain user wouldn't have the rights necessary for writing to the directories. I've never heard of issues compiling a kernel as root, and most everyone does it in this manner. I don't know of any guides that suggest doing it otherwise, or any reasons to do such.

Note that these directions are for compiling from pure source, not rebuilding a source rpm.

What about multimedia kernels? I've seen that there is "kernel-multimedia-2.6.14-0.mm.7mdk-1-1mdk.i586.rpm" (http://www.mde.djura.org/2006.0/RPMS/kernel-multimedia-2.6.12-12.mm.13mdk-1-1mdk.i586.rpm) and kernel-2.6.14.1mdk-1-1mdk.i586.rpm (ftp://mandrake.contactel.cz/Mandrakelinux/devel/cooker/i586/media/main/kernel-2.6.14.1mdk-1-1mdk.i586.rpm)
Which one to use? Which is better and what is the difference?

I would also recommend reading the kernel build how-to on digital hermit site. It contains generic instructions, but is worth reading anyway.

If I remember correctly, that how-to also explains how to patch a vanilla kernel with, e.g., "multimedia" patch. -mm patches are, according to kernel.org, "more experimental".

Hi Ian
All done and it worked fien, only problem , as expected I lost my nvidia drivers because I suppose the kernel-source does not match the kernel. Sorry, I just went back to init3 and relaunched the NV installer and all is now in order, I will now try my software to see if all is ok.

uname -a :
Linux linux-box 2.6.15 #1 Sun Mar 12 17:58:03 GMT 2006 i686 AMD Athlon™ XP 3000+ unknown GNU/Linux

I didn t need to touch Lilo, it was uodated automatically.

Maybe a stupid question but do I leave my rpm update on automatic? Will the updates that I get from ftp servers be understood by the new Kernel or do the assume I still have the 2.6.12?

Stef

There is a realised patch for 2.6.15.You can download it from here:
ftp://ftp.openbios.org/pub/bootsplash/ker...1.6-2.6.15.diff
I've tested it and it works!

To apply the patch follow this instructions:

And then u have to change your configuration of the kernel with "make xconfig" or "make menuconfig" if its not changed.U should enable "Frame-Buffer support" and select "VESA VGA graphics console" in the Console Drivers section.You also should disable "Use boot logo" and enable "Use splash screen".

Or just patch it with ArchCK... http://iphitus.loudas.com/archck.php

end plug

It won't automatically update your kernel. What might be best to stop kernel-source upgrades is to remove mandriva kernel-sources, and just leave the 2.6.15.6 kernel source in place. That way it'll never attempt to update the kernel source, and you can do all this manually at your leisure.

Note, that if for example 2.6.16 came out, you could download the source, and compile in the same manner, since it would read your existing config. To make sure that this reads your 2.6.15.6 config, make sure symlinks are updated in /boot so that they point to 2.6.15.6 and not 2.6.12.17 or whatever you have installed with Mandriva.

You will not be able to remove your Mandriva 2.6.12.xx kernel, I just tried on my test system and it said it will break your system

But it's there as a fall back in case of any probs using 2.6.15.6. Enjoy

Yes, this works. To find the options in case you're unsure of where they are, this is how I did it:



exit and save, and then this is when you compile the kernel using the commands I listed before.

I've not used the archck link iphitus posted, as I'm unsure of whether this relates just to the "arch" distro, or is generic.

I wouldnt have posted if it wasnt generic, there would be no point in doing such. By their nature though, kernel patches and patchsets are mostly distro inspecific.

The poor name is a hangover from when I used to solely make it for the Archie liveCD. It's branched out since and is used by a heap of Gentoo, Arch, Fedora, and other users....

iphitus

Ah OK, cool

Two patches for anyone to use now!

After installing 2.6.15.6 there is an error while boot:

But /dev/hdc exist!!! How to fix this?
Edit: I've returned to the old 2.6.14-mm because of this :(

Check your /etc/fstab. If it mentions supermount, then this could be the problem. My cd-rom's are configured for "auto" and therefore mount no problems with 2.6.15.6. When you compiled 2.6.15.6 were you in your 2.6.14 mm kernel? If so, this could also explain why.

This howto was written on the basis that you have a Mandrake/Mandriva kernel installed. A stock kernel that has settings relevant to Mandrake/Mandriva. On this basis it works. I've no idea how your 2.6.14mm kernel has been configured, so it could be you missed a setting somewhere, which is why you are now experiencing problems. If you can, I would suggest you boot into a Mandrake/Mandriva kernel, and then rerun the compile, making sure that your /boot/config symlink is pointing to a Mandrake/Mandriva config file.

The only problem I've found so far is with the mandi service failing, probably due to some patch applied to the kernel. This isn't required anyway, as shorewall will work perfectly well without it. It just means if you configure using mcc, you have to disable the interactive option and when prompted to install mandi-ifw to click cancel, and just install shorewall after this.

ianw1974 the cd-rom is with auto option in fstab.I havent edited the 2.6.14-mm kernel.I just downloaded the rpm, recompile with athlon optimizations and installed.Thats it.

any idea how to deal with that supermount option on 2.6.15? I tried 2.6.15 already and got to successfully install it from source, but after booting on it, I encountered the problem regarding supermount, and it seems that its not supported on 2.6.15, or any 2.6 kernel that comes directly from source... but on mandriva distributed 2.6.** kernel, supermount is supported... below on the first image, taken when I tried to compile the 2.6.15 from source (which came from kernel.org) and took the snapshot on the psuedo file system portion



and it does not show any supermount option to enable, while on the next image, snapshot taken on 2.6.12 kernel that came from mandriva LE 2005..


see, there is a supermount option to define...
.
due to that ( no supoermount), I can't mount or access the CDROm drive.
.
any idea?

I think it needs a patch applying. I'm currently looking for one now to check/test.

EDIT:

scrap that, the patch isn't released for later kernels and the one I downloaded only is as far as 2.6.3 and causes a few problems in that it won't compile. I have seen another option, but I'm just getting my kernel-source clean again after the patch applying. Will update this post once I've enabled the option in the kernel for automounting.

I have the same Problem with my CDROM, I have to mount it manually.
Stef

I've been doing the same now. What I have noticed is that under File Systems --> Kernel automounter version 4 support (also supports v3) is enabled and selected as a module.

I think this is what is the alternative, and I think you need to urpmi autofs and have this service running, and then configure using the /etc/auto.master file as /etc/auto.misc file to access the CDROM and get it to mount. Unfortunately it hasn't worked as of yet, but I'll keep trying.

The other alternative is trying to find the right patch for supermount to apply to the kernel and then compile.

Link: http://www.linuxhq.com/lg/issue24/nielsen.html

ur a genius Ian
.
thanks for mentioning autofs,... did you know that my primary reason of installing new kernel is to overcome some problems I encountered with autofs, but that's a network related one... but then, when encountered a problem with "supermount not supported" on kernel 2.6.15, I forgot that cdrom can also be mounted using aufofs, so now, I can mount it via autofs...
how?
.
install autofs
.
then edit /etc/auto.master
.
sample:

then check your /etc/auto.misc , the entry that refer to cdrom

above is the default /etc/auto.misc
.
to access the cdrom, you cant directly click the icon, since it refers to /mnt/cdrom and the entry above has a name "cd" only, the first part followed "-fstype=iso9660,ro,nosuid,nodev :/dev/cdrom" so to access the cdrom, you just have to browse /mnt/cd or "ls /mnt/cd" thu you dont have to manually create the /mnt/cd folder, since it is defined on /etc/auto.master "/mnt /etc/auto.misc" that "cd" should be mounted on "/mnt"
.
then you just have to create a shorcut of it on the desktop.
.
oh.., btw, dont forget to run autofs as service, then everytime you edit autofs, as root, do a "/etc/init.d/autofs reload"

I've changed it so it works that way no need for desktop icon, as you can pull it straight from the Devices icon.

Here is what you need to do:

/etc/modprobe.conf



now, that will sort out the module side of things. Now:



add this to /etc/auto.master:



now create /etc/auto.cdrom:



start the autofs service:



now you can use your system normally. It uses /media/cdrom correctly, and you can also do similar for your floppy drive as well. See the howto I previously posted a link to, but keep the format the same as the above so it uses /media/floppy. Otherwise, it tries to use /media/floppy/floppy as per the howto and doesn't work. By just specifying /media in auto.master, it then appends cdrom from auto.cdrom thus creating /media/cdrom as the mountpoint. If you have /media/cdrom in auto.master, it then tries to create /media/cdrom/cdrom.

If anyone else has upgraded their kernel following this guide, please post your problems and/or resolutions if you have any. That way, we can make sure that if someone does attempt a kernel upgrade, they have all the info they need to get themselves up and running.

I couldn't find a supermount patch, so I presume that Mandriva have modified their own version, since the latest patch was for kernel 2.6.3. Don't bother to apply this, it screws the kernel-source, and you have to clear it and start again. I tried. The autofs approach is by far better.

hey ian... can you observe if it really unmount the cdrom after 10 seconds of timeout that you've set

If I put a CD in it stays mounted. When I eject it, and try an immediate ls /mnt/cdrom it fails to list anything. Note however, the mnt/cdrom directory is hidden when the disk is unmounted, and only becomes visible when you put a disk in the drive.

I think the timeout would take place if it can't read the disk, and therefore doesn't mount it.

try also if any of your cd burner will work on that situation since mine wont, though it automount when I do ls /mnt/cdrom
.
timeout should takeplace even if the disk is on the drive but you did not access it or no open files on it for the specified time

I just put blank cd in, and then burnt a cd no problems. However, this was copying openoffice2 rpms that I downloaded to install on my machine here, and then take home to save downloading twice (my internet slow at home).

I then mounted it OK too after burning. If I experience any probs, I'll remove the timeout line. But seems to be working OK now. And it didn't unmount if I didn't use it

I've made changes to the autofs post. I've replaced /mnt with /media, because I then found that when autofs is controlling /mnt you cannot access your /mnt/windows partition.

Therefore, creating a /media directory, keeps your hard disk mounts separate from your removable media mounts, and is more stable.

I cant believe mandrake still use supermount. Ugh.

You ought to be able to get their patches, by grabbing a src.rpm for one of their kernels, and extracting that.

and would you believe that on opensuse 10.1, they will drop the subfs, which is equivalent to supermount on mandriva....

ian... I'll try that tommorow, am using windows right now , ..googled about supermount patch, and it shows that there are patches on it but for kernel with previous version, I dont know if it could be applied to the latest one



hmmnn.. I did'nt feel it, coz I dont have a windows partition on my desktop anymore, but on other machines, I have a linux partition under mount, I'll check it later...

I tried the supermount patches for 2.6.3 and they didn't work. So have a funny feeling unless it's for the current release it won't. autofs works good for me, so am happy with this as a solution to the supermount problem.

Hi Ian!
I ve followed your instructions and now the cdrom is mounted automatically on /media/cdrom... BUT (he he he) I still can t acces it if I click on the cdrom icon in the "devices" section of my KDE Desktop,

Any Clue?

Stef

You're going to have a hard time getting patches from older versions working ianw1974. Most
patches are extremely version version dependent, especially things like supermount which is somewhat invasive.

If mandrake is still including supermount in their kernels, you can get your hands on a copy by extracting the src.rpm.

iphitus

you cant access it using the cdrom icon on your desktop since that icon is still pointed to the entry in your fstab which uses supermount, so to access the cdrom drive, you have to open your file browser and browse into
.
/media/cdrom
.
or put a shortcut or link of it on your desktop, the side effect, under supermount, you can just right click on the cdrom icon then unmount it, now, in my box, there is no option to unmount it, I should have to eject the cd to unmount.

btw, when pointing the cdrom into /mnt/cdrom. it affected all the folder under /mnt, I can't see them anymore once autofs start, so I changed it to /mnt/media/cdrom ( same by doing /media/cdrom) and all works fine, cdburning now also works fine, The onyl thing I still have'nt tested is the floppy ..

Hi

Thanks Aishin, It does work perfectly now. The cd and DVD Writing and ISO creating works here too.

Thanks to all, really great howtos, please keep the link alive and help newbies like me to make the most of the kernel!

Stef

That's funny, cos I can access my CD through my devices icon. I've changed /etc/fstab, so that my /dev/hdc is now /media/cdrom instead of /mnt/cdrom as it was previously.

Here is my stuff, so you can see all my config files relating to the cdrom configuration:



and attached screenshot to prove the devices cdrom browsing.

Hi There!

Since I compiled 2615 I have a few "symptoms" indicating threre are a few bugs in my config. Not quite sure what to do about it so I thought I d grep /var/log/messages and ask you all what's the situation.
Practically, I have a ~30% failed booting where the system just stops after the 10 first lines of verbose -> reset button and it all starts as if nothing happen (not even a filesystem check). Otherwise my cdrom still is not that perfect it seems it doen t want to mount /media/cdrom (normal if there in no cd in the drive isn t it?)

Code is a s folloW:



Thanks!

Stef

mandi is failing because of the kernel, because it's probably patched for it. I mentioned this somewhere on page 1 of this whole post and how to get around this. Basically urpme mandi and shorewall, and then reinstall shorewall but do not use the interactive option and click cancel when prompted to install mandi-ifw.

The rest don't look like kernel problems. sshd is saying something else is already listening on port 22. use netstat -tan to check what is running. Bind could have failed because of a config option, this is normally the case when I've been using it. Try starting the services manually once your system is booted, and then see what errors you get for each one.

I can only suggest looking at the log files in more detail for more specific issues that might be the cause, not necessarily the kernel. Boot back to previous kernel, what version are you running prior to the upgrade?

Thanks Ian,
I ve removed shorewall and will give a go to firestarter to see...

Stef

Waow! I have a new symtom doctor, what a plague I am!

Here we go : I can t start my diskdrake anymore!


And Guess what? I don't have aclue what I 've done to deserve that!

I know it's probably not a pb of Kernel, but it is since I have gone to 2615 that I got that.

Any Idea?

Stef

Autofs causes this. If you stop the autofs service, you'll probably find it'll create the directory. I tried to manually create /media/cdrom and it gave the same error message.

It locks the /media directory so that nothing else can create the same directory names as it is using for it's automounting. When the service is stopped, of course, then the directory can be created.

ok, as mentioned on my other post related to automount|autofs with a problem that it wont auto-unmount, now, I've tested it on my 2.6.15 kernel mounting cdrom with time-out of 10 sec., after not using the cdrom, it will now auto unmount it..

Remove autofs then replace it by installing autofs from source .
.
from here:
http://www.kernel.org/pub/linux/daemons/autofs/v4/
.
and it fix the problem

Edit:
btw, with regards to mounting floppy if using entry below

it will not allow you to mount or open the floppy as a regular user, but you can as root only, using the entry below

allow a regular user to open it or mount it...
.
and after several seconds (as set in timeout say 6 seconds) it will auto unmount (should be) and a user may remove it without needing to manually unmount it

Greetings to my fellow open source idealists.
I have come across a even easier way to upgrade the kernel, from the Mandriva Club and other Mandriva forums, I upgraded from 2.6.12-12mdk to 2.6.12-18mdk on a Mandriva 2006 power pack-Athlon XP system.This is not my own work as I am just at the begining of understanding of linux configuration :)

Step 1 Mandriva Kernel Update

There are a few steps to installing a new kernel that is released by Mandriva for the Mandriva Linux distribution. While it is certainly easier to install kernels now than it used to be, a few precautions will ensure that if you do have any difficulties with the new kernel, you can boot into the previous one.

x86 and amd64 Kernel Updates :
Open a terminal as root and update your urpmi sources: (# denotes su command in a terminal )

# urpmi.update -a

Read the advisory so you know what kernel version to install; for instance if the filename is
kernel-2.4.19.24mdk-1-1mdk.i586.rpm you will want to execute :

# urpmi kernel-2.4.19.24mdk

This will install the new kernel alongside any old kernels that are currently on your system.
Next, edit the /etc/lilo.conf or /boot/grub/menu.lst file (depending upon your bootloader). Ensure that you will be able to boot your old kernel by making sure a stanza exists for it specifically. If this is your first kernel update on the system, you likely will have two stanzas that point to symlinks; the kernel installer always updates these to point to the latest vmlinuz and initrd.img files. Usually a copy and paste of the new kernel stanza and modifying the kernel number is all you will need. For instance, if the new kernel is 2.4.19-24mdk and the release kernel is 2.4.19-16mdk, copy the -24mdk stanza and replace -24mdk with -16mdk.
If you use lilo, once you have modified your /etc/lilo.conf file, you must execute "lilo -v".
Grub users do not have to do anything extra. Now you can reboot into the new kernel.

(When I did this it automatically updated my lilo.conf and executed lilo)

PPC Kernel Updates :
The PPC kernel updates are virtually identical to the x86 updates, the only real difference is
that PPC uses yaboot for a boot loader, rather than lilo or grub. The file you need to edit is
/etc/yaboot.conf and, like x86 users, ensure there is a stanza for the old kernel so you can
easily boot into it again if you encounter problems.
On some older PPC distributions, you may need to manually create a new initrd image with USB
support for keyboards and mice. This can be done by executing, as root :

# mkinitrd --with=usb-ohci /boot/initrd-2.4.8-31.3mdk 2.4.8-31.3mdk

Of course, replace the kernel version with that of the kernel you just installed.
Finally, to commit the changes to the bootloader, execute "/sbin/ybin -v".

Step 2 DKMS

( All I did here, after Step1 & kernel-source upgrade, was uninstall all of my nvidia 7174 packages and installed dkms-nvidia 8174 package with MCC ,,then success :) )

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/mandrake...86/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 2: Another example of using dkms is presented by Buchan Milne, who is the major contributor of dkms in Mandrakelinux :http://forum.mandrakeclub.com/viewtopic.php?p=119002#119002
Here he shows the install of the pwc driver (Logitech/Philips webcam). He has also many dkms drivers, still in testing, there: http://plf.zarb.org/~bgmilne/dkms/ This FTP resource may be added as a urpmi media (see documentation, the knowledge base or my guide at http://www.zebulon.org.uk/ICML0.HTML ).

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
Smile

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 and thanks to all working on the kernel

how does arch handle the pseudo filesystem?, or the removable media... or what's the equivalent of supermount on arch anyway?

We know about the urpmi kernel feature. The problem is the latest kernel is only 2.6.12 (regardless of .12, .15, .18 they are still 2.6.12).

This post was to use a more up-to-date kernel, 2.6.15, hence the manual creation, which was pretty easy and straightforward, apart from the fact that Mandriva heavily patch them, and we worked around these issues with autofs instead of supermount, etc, etc.

This post is useful for those who have new hardware, that's not supported by the urpmi kernels, and therefore allowing you to use Mandriva on your machine with the new kernel and the hardware that you can now use!

It probably wasn't clear, I suppose I should have explained why this method was being used instead of the so-simple urpmi kernel upgrade.

You gotta remember, that these automounting solutions are generic and could work on any distro. Arch by default does not setup any automounting. If you do want it though, you could use any of ivman, supermount, autofs, and others. There's a range in the repositories.

Under KDE and Gnome, their respective inbuilt automounting tools are enabled.

James

Ok Moriarty's post is in a way was off topic, BUT it has been very useful to me as i did not have a clue what DKMS was and was recently a bit too lazy to google that. I will now print his post (on recycled paper!) and read it...

STef

It's not completely correct about DKMS. You don't have to uninstall anything when a new kernel is installed. When you reboot the system, the dkms service checks/detects whether the dkms-nvidia module or whatever module is installed into the kernel. If it's not, it installs it during bootup, so that when you launch X, you have your nvidia drivers.

Normally, if you use nvidia's driver from their website, you have to reinstall the driver manually because it's not automatically updated into the kernel, because it was installed/compiled with the previous kernel-source.

DKMS just saves you having to manually reinstall it after the kernel upgrade, and allowing you to save on one more additional reboot after a kernel upgrade.

On 2.6.15 hotplug isn't just deperecated- its kicked out completely- maybe this is your problem.
2.6.15 should be used with a fairly recent udev/dbus/pmount combo, all other (super)mounting utilities shouldn't be used.
I'm sceptic though on how well the Mandriva initscripts work with 2.6.15... there should be some issues.

The booting of the kernel was perfectly fine. Of course, it would require testing on all different types of hardware to find out if there are actually any issues.

The kernel compilation reads the /boot/config file for all current settings of the existing kernel, so it should practically all be the same apart from any patches that Mandriva introduce to their own kernel. Of course, we have no information whatsoever on what they do to patch it other than what we've found so far. There's obviously something patched onto it for mcc, since we've seen a few issues here too. But then if you can configure your system manually from the command line, and you're able to compile new kernels successfully, this isn't a major problem in itself

In all honesty, it's probably just best to stick with the urpmi kernels unless you really have to use a newer kernel. Then, this post does work for that need, and issues logged in here so far have pretty much all been resolved (bootsplash/autofs instead of supermount).

I have a quck question on some post-kernel installation actions. I have s touch screen display that I have working with the old kernel. The "evtouch.o" file is in the X11 input module directory. I know I can rebuild the file for the new kernel but it will then make it unusble for the old kernel. How can I set this up for a two kernel boot option?