SARK UCS/MVP Development Note... Asterisk, DAHDI and the Kernel drivers

An explanation of why the "kmdl" issue is critical and a suggested (temporary) workaround.

When we look at the questions which come into the Forum a good deal of them are of the form "I yum upgraded my system and SAIL has stopped working". Actually, SAIL is pretty resilient to these upgrades but Asterisk, or more precisely, Zaptel/DAHDI isn't. This has to do with the fact that the Digium card drivers need to be loaded as part of the kernel (using insmod or modprobe) and the drivers themselves are actually stored in the kernel directory structure (usually in /lib/modules/kernel-release/extra or /lib/modules/kernel-release/update/extra). When the kernel changes (as it often does after a yum upgrade), Asterisk cannot find its drivers anymore (because they are in the directory structure of the old kernel, but not in the new one). ATrpms try to minimise the work they have to do by separating Zaptel/DAHDI rpms into two parts; the core release (1.4.xx) and a kmdl release which just contains the kmods for a particular kernel.

Now, it is by no means guaranteed that ATrpms will have a kmdl release available for your particular kernel whenever you do a yum upgrade. So, before you run a yum update, use yum to check whether it will update the kernel by issuing the following console command...

[root@sam SPECS]# yum check-update | grep -i kernel
kernel.i686 2.6.9-78.0.13.EL smeupdates
kernel-smp.i686 2.6.9-78.0.13.EL smeupdates

You can now check ATrpms to see if the is a zaptel/DAHDI kmdl for the new kernel release before you do the yum update.

If you didn't do the check and you are now in trouble, the easiest thing to do is simply start your SME Server on the old kernel. When yum installs a new kernel it doesn't throw the old one away and you can usually just start SME on the old (previous) kernel by pressing the space bar when the penguin/SME server splash screen appears at boot time. This will show you a list of all of the available kernels and you can choose which one you wish to start.

If on the other hand you absolutely must run the new kernel for some reason (perhaps it fixes a big security hole) then you can usually get away with copying the contents of the /extra/ directory from the old kernel tree to the new one (at least until you can get hold of the correct kmdl rpm)...

cp -a /lib/modules/_old-kernel_/extra/* /lib/modules/`uname -r`/extra

This won't work if you have moved from an EL kernel to an ELsmp kernel, or vice versa, but for most other changes, you should get away with it. We don't recommend this practice and we certainly don't guarantee that it will work. You are on your own. If it breaks your SME install then you get to keep all of the pieces. However, suffice to say that it has thus far worked for us.

S