-   Slackware (
-   -   word to the wise: when recompiling same kernel version, watch your /lib/modules/! (

stabu 03-31-2007 04:34 PM

word to the wise: when recompiling same kernel version, watch your /lib/modules/!
Wow, have I had a bit fun today. I was deploying a new iptables script which looked for IP_CONNTRACK which I noticed I did not have set up in the kernel so I decided to recompile.

It's been a while since I recompiled, but it took longer than expected (considering the small change I made) but anyhow, I rebooted with the new kernel image and I got problems, so I said, OK, it's a bigger problem than I thought, leave it for another day.

So I tried to boot back into my old kernel image. No reason for it not to work, right? I've done this tons of times with no problems.

However, I did get a problem. A segmentation fault, no less, during the running of rc.inet1. The process at fault (it says) is dhcpcd. The problem is real similar to Charred's here:

This caught me by surprise. The old kernel image must have been affected the recompile of the new image. I had not thought of this before. I mean, if you compile a new version of the kernel, a new directory with the version number is created in /lib/modules. But if you recompile the exact same version of the kernel (maybe because of minor change) the /lib/modules/$(VERSION_NUMBER) directory is written over with the new modules. The old kernel image will use this newly written directory

Now I am wisened on to this, in future I think I will take a copy of the old /lib/modules/$(VERSION_NUMBER) directory just in case stuff like this happens.

Of course, I have yet to find out what exactly happened. How could the modules get so mucked up during a recompile? Of course, I'm only at an early stage of troubleshooting. I'm just really surprised I hadn't come across this problem before.

arcanex 03-31-2007 05:16 PM

Unless you did a 'make modules_install', it shouldn't have copied the recompiled kernel modules over to '/lib/modules'

bl0tt0 03-31-2007 05:52 PM

best solution to this kind of problem is to add a localversion string to the kernels you compile. It's the first option in General Setup. I've made it a habit to just put the date in as the localversion string. That way, whenever you make modules_install, a new directory is creating in /lib/modules with the date as an additional string. It definitely makes it easier to keep things clean.

gnashley 04-01-2007 02:54 AM

I usually just change the name of the directory with the original modules just before running make modules_install.
The error you got probably came about because of hard-linking a feature which also has a module installed. modprobe tries to install the module, but the feature is already in the kernel so you get all kinds of paging and memory allocation errors.

stabu 04-01-2007 09:29 AM

Many thanks for the replies!

Yes, a little too much fiddling was to blame. I've got it all back now, with a new, further slimmed down version of my kernel.

LazyP 04-02-2007 06:26 AM

Apart from appending a localstring for every kernel compilation, you should check whether you really need to recompile. If you want just another module you don't have to recompile the whole kernel. Just compile the module instead. Do a make help to get further instructions.

onebuck 04-03-2007 07:59 AM


Just change the ExtraVersion to something unique in the Makefile. That way you will have modules for that compile session.

duryodhan 04-03-2007 12:07 PM

stabu : The reason you ran into problems could be because the is different for both the kernels?

All times are GMT -5. The time now is 11:52 PM.