modversion issue on redhat 9 (Jun Sun)

Harry Moyes harry at shoka.net
Thu Aug 28 19:15:35 EDT 2003


On Wed, 2003-08-27 at 15:49, Ged Haywood wrote:
> Hello there,
> 
> On Wed, 27 Aug 2003 Jun Sun wrote:
> 
> > Basically if you compile hostap modules for a redhat 9 box, you
> > will end up many unresolved kernel symbols when you install the modules.
> > 
> > The problem is that hostap would include linux/modversions.h file ahead
> > of all other header files, but in reality this file needs to be included
> > after linux/rhconfig.h file because many #ifdef's used there.
> 
> I'm not sure that's the problem.
> 
> I think you might find that the kernel and modules that ship with RH9
> were not compiled with the .config that you used.  If you recompile a
> kernel or any modules with the .config that came with RH9 you may need
> to reinstall all the modules as well as the kernel.
> 
> You can always just compile everything with CONFIG_MOD_VERSIONS not
> set in the .config but that's asking for trouble later on if you have
> more than one build on your system.

You don't **have** to give up on module versioning

RedHat want to keep the pristine tested kernel that they ship with the
system, and its set of matching tested modules. 

The kernel source tree as installed by the source RPMs does not contain
a .config file. If you generate a .config file to match the existing
kernel with (say) make oldconfig, or generate a new one with make config
and friends, RedHat arrange that "custom" is appended to the end of the
version string.

If you build and install this kernel and its modules, its added as an
option to the boot loader (not the default option either). You can thus
build and test it without risking having an unbootable system 

This is all fairly sensible, since if you screw up you continue to have
your original RH supplied kernel and modules to fall back on.

As an unfortunate side effect, if you simply create a new .config file
but do nothing else,when you build hostap against this .config file and
the supplied source tree, hostap will be built with module versioning to
match a mythical 2.4.xx.xxcustom kernel, and the resulting Hostap
modules will not load against the default kernel

By repute the required .config file to match the default kernel as
shipped is defconfig deeper in the source tree under say
/arch/i386/defconfig. I can't confirm that copying this to .config in
the usual location and recompiling hostap will yield hostap modules with
versioning to match the default kernel as I've never tried it myself,
but at least one source I've seen contends that it does.

Alternatively (as I've done) go the whole hog, and build your custom
kernel and modules, boot from it and your shiny new hostap modules
**will** match the running kernel, and load correctly.

So IMHO its a very sensible RedHat built safety net, that unfortunately
fails to take into account building an "external"  module within the
source tree, without rebuilding the kernel itself.

When RH 8.0 was new and shiny, there was a flurry of posts with versions
of this issue. I posted a cookbook suggestion then that got a few folks
out of trouble. Maybe adding something similar to the above to the FAQ
would help folks avoid this particular pitfall.

Harry
 





More information about the HostAP mailing list