[lug] Kernel compile issues was: Re lpc status and sh

John Karns jkarns at csd.net
Fri Nov 23 08:30:17 MST 2001


This is somewhat old mail - the msg somehow ended up in postponed msg
limbo for several days.


On Wed, 14 Nov 2001, D. Stimits said:

> The module install step creates the directory.

It may be that I had the format wrong:

> > EXTRAVERSION =-TestRun
> > (note that there is no space between the "=" and the "-")

I may have neglected the space.  In any case, a directory was present, but
when the kernel attempted to load modules, it couldn't find them.


> 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

I always do the "make modules_install" so that any relevant would be
copied to /lib/modules.  However, in reverting to a previous kernel there
may be problems if a module dependency had been broken by the newer kernel
cfg.

I don't know if the modules are relocatable or not, but had assumed that
they are.  If that is true, then the issue may be one of module
interdependencies.

I've rarely seen any unresolved symbol errors with more recent kernels.  I
recall that with earlier kernels lots of errors would spew out, but they
were generally a consequence of the system trying to load non-existent
modules AFAIK.

> 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.

Maybe it's because I usually make small changes between successive kernel
cfg's, but I don't recall having encountered the unresolved symbol error
issue that you speak of; but I *do* recall seeing some of this when
running "depmod -a" after making changes to /etc/modules.conf.  Would this
what you're talking about?

----------------------------------------------------------------
John Karns                                        jkarns at csd.net






More information about the LUG mailing list