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

[D. Stimits]

John Karns wrote:
> 
> 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.

The space on the left side of the "=" doesn't matter, it is the one on
the right that matters. What will happen is the space will be
interpretted literally as part of the name, at least for some portions
of the kernel build, but not others. So if the basic version is 2.4.15,
and you used:
  EXTRAVERSION = -TestRun

Then the full version is: "2.4.15 -TestRun". How that behaves when
passed on to other parts of the install depends on whether it is quoted
or not...some portions of the build and install will consider it 2.4.15
(and possibly croak on the -TestRun as another argument, or silently
throw it away), others as "2.4.15 -TestRun". You can have spaces in file
and directory names, but that usually requires quoting to avoid
surprises. I don't know exactly what part would fail if there is a space
in the name. Configuration is one of those things that gets bug fixes as
time goes by, so maybe someone has started stripping out the space by
now, but I don't think it is done yet. Keith Owens of SGI and XFS
filesystem fame is doing a massive rewrite of the kernel configuration
system for the 2.5.x kernels (and 2.5.0 is out: try "finger
@kernel.org"), it's supposed to be much more sane for developers (and
possibly users).

> 
> > 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 personally keep an archive in a protected directory of every kernel
config that goes in. I never install one kernel with the exact full
version name the same as a prior kernel, unless I have first tested it
under an alternate name, and then done a full rm -Rf of the particular
module subdirectory. Having extra modules is in many ways worse than
missing modules.

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

There is a kernel option for setting version number in modules, I don't
recall if this makes it possible to relocate or if it makes it
non-relocateable.

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

I didn't think that missing modules had unresolved symbol errors, I
thought it was a case of symbols being presented to the kernel which
hadn't been "registered". But then again, some modules depend on other
modules, so I suspect it is a complicated answer. Without a doubt,
inserting a module that wasn't accounted for in configuring the compiled
kernel will spit out lots of unresolved symbols.

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

I would guess that the original poster had changed which modules were to
be compiled and failed to do a full make modules_install. If that
happened, even modules that *had* been allowed in the kernel might have
changed in such a way that they were rejected. Does anyone here know if
modules 100% relocatable, or if they have to match some offset in the
symbol tables? My suspicion is that they do (I always compile in
versioning though, which might change the answer).

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