[lug] Re lpc status and sh

D. Stimits stimits at idcomm.com
Wed Nov 14 15:38:54 MST 2001


John Karns wrote:
> 
> On Tue, 13 Nov 2001, D. Stimits said:
> 
> > One of my favorite tips is to choose a new "EXTRAVERSION" in the
> > Makefile before starting. When you run "uname -r", and get back
> > something like 2.4.9-15smp, the "-15smp" is the EXTRAVERSION. This stops
> > your original kernel and modules from being overwritten during the
> > install, and it can be used to append to your System.map file as an aid
> > there too (anyone seen unresolved symbols while loading modules?). E.G.,
> > edit /usr/src/linux/Makefile, find the EXTRAVERSION line, and do
> > something like:
> > EXTRAVERSION =-TestRun
> > (note that there is no space between the "=" and the "-")
> 
> I like this idea, and seem to recall having seen it mentioned on this list
> once or twice in the past.  I tried it once, but had a problem with
> modules not loading - I recall seeing errors about the directory not
> being found.  But I'll have to give it another go, as I like to
> have a more than one kernel to choose from.

The module install step creates the directory.

> 
> > Doing a make modules-install would then write modules to a new
> > directory /lib/modules/2.4.15-TestRun/, rather than overwriting or
> > getting mixed up with prior modules.
> 
> I'm not sure I like the idea of having a bunch of module dir trees around
> though.  AFAIK the 'make modules_install' just copies rather than deleting
> the existing modules first - i.e., it's accumulative - so I like the idea
> of having one set of modules for different kernels of the same revision
> level.

As soon as you eliminate a kernel, delete the tree. But you *MUST* have
the proper modules for a given kernel if you want to avoid problems. If
you fail to delete a module in a current directory that is no longer
compiled as supported, you'll get attempts to load the module sending
out unresolved symbol errors. And if for some reason your newer kernel
uses the same module name as an old one, but function calls inside it
have changed API, you'll probably get a hard lockup or kernel oops that
is non-recoverable. All modules were not created equal, they deserve
their own directory. But if you really want to try it, just rearrange
the modules via symbolic links to give one directory multiple names. The
kernel itself looks for modules based on version number scheme, this is
already default behavior. What it doesn't do is work around two
different kernels having the same name but different features.

D. Stimits, stimits at idcomm.com

> 
> ----------------------------------------------------------------
> John Karns                                        jkarns at csd.net
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug



More information about the LUG mailing list