Re: How to handle kernels of the same version

[jfm2@club-internet.fr]

> 
> I've known for a while now, but just now had a chance to implement, how to 
> handle several kernels of the same version, while maintaining the ability 
> to use modules.  It's a simple concept really, and a very simple 
> implementation.
> 
> The basic concept is to use the kernel version number (rather than the 
> kernel version) to index the modules.  Every kernel is built using a 
> version number, the previous kernel having been built with the number 
> stored in /usr/src/linux/.version.  This it the value you see when you do a 
> uname -a:

The simpler would be to use compilation-time as a subdirectory and
hack the kernel scripts for making them install the modules in
/lib/modules/$kernel_version/$compiltime_version

Notice however than we don't really need to handle many kernel
versions.  What we need is to keep sane the modules for the safety
kernel (the one he used for install that we would be keeping just in
case).

Having a tgz containing the safey kernel's modules in the root
peripheral and a command for moving the production modules out of the
way and reinstalling the modules for the safey kernel is perfectly
valid.

By lloking at /proc you can know the arguments to the kernel and pass
a special arg thanks to LILO.

> 
> Linux psi.int.omegacs.net 2.0.32 #1 Sun Nov 30 15:34:00 PST 1997 i586 unknown
> 
> Since /etc/conf.modules can specify paths to the modules directories, and 
> since they are passed through a shell for expansion, as per the 
> documentation, we can not only specify the kernel version, but the version 
> number:
> 
> path=/lib/modules/`uname -r`-`uname -v | cut -c2- | cut -d\  -f1`
> 
> There are quite a number of paths to set, including that of every 
> subdirectory (block, cdrom, fs, ipv4, misc, net, pcmcia, scsi), and the 
> path to the modules.dep file.
> 
> However, once these are set up properly, you can boot to any kernel you 
> want, as long as you have the modules in the right place (i.e. 
> /lib/modules/2.0.30-2), and the kernel actually matches those modules.
> 
> In order for the modules to stay in sync, however, we'll have to be very 
> careful with the .version file.  The kernel Makefile will automatically 
> increment it by one during a build of zImage, so as long as we find the max 
> of the existing kernel version numbers on the current system and put that 
> in .version before building, we should be OK.
> 

If you erase and reinstall your kernel sources the .version will be reset.


> If anyone has a machine to play around with this on, see if you can come up 
> with some scripts to handle setting the .version file correctly, building a 
> kernel, and installing everything in the right place.  For now you can 
> assume that you're being given a correct .config file.
> 

I have the box.

-- 
			Jean Francois Martinez

"For drinking muddy water if that is the water of truth,
            for that the camel is needed"