[lug] iptables unresolved symbols

D. Stimits stimits at idcomm.com
Tue May 22 10:38:19 MDT 2001


Lindsay Haisley wrote:
> 
> Has anyone found a solution to this?  The problem is still there as of
> kernel 2.4.4.  A little research turns up the fact that the 'unresolved
> symbol' errors are apparently related to what look like non-standard
> module version tags on symbols that can't be parsed by modutils tools.
> running depmod against System.map, or on a kernel compiled w.o. module
> versions in symbols, produces no unresolved symbol errors, whereas if
> they're present, one gets the error.

Every kernel compile alters the table of symbols (function location
info) that modules use. System.map is custom to each compile of the
kernel as well, which is probably why it is failing for you (your
kernel/module combination does not match the System.map). If you go into
the kernel Makefile at /usr/src/linux/Makefile, you'll see an
"EXTRAVERSION" line, which most distributions add something to, and to
which stock kernels leave blank. If you have a stock kernel (for
example) version 2.2.18, then the basic lines in the Makefile are:
VERSION = 2
PATCHLEVEL = 2
SUBLEVEL = 18
EXTRAVERSION = 

With this, you can name your System.map as:
System.map-2.2.18

If you have patched the kernel, or want to mark it any way, you can add
to EXTRAVERSION (Redhat and most distributions label based on patching),
such as:
EXTRAVERSION = -May22

In that case, you would label System.map:
System.map-2.2.18-May22

This would allow the kernel that has this Makefile setting to find its
System.map in /boot/ mixed in with other System.map's and other kernels.
System.map should be generated in the /usr/src/linux/ each compile.
You'll also find that EXTRAVERSION helps keeping track of modules.
Modules are normally stored in /lib/modules/<version number>/. If your
kernel was 2.2.18 and there is no EXTRAVERSION, you'd have modules in:
/lib/modules/2.2.18/

Recompiling will overwrite those modules (make modules_install), but old
ones that are no longer used will be left there to cause problems, such
as annoying messages about being unable to load when you have in fact
compiled support directly into the kernel (in which case it can't load
the module because the code is already in place). With "EXTRAVERSION =
-May22" instead it will store in:
/lib/modules/2.2.18-May22/

That'll save your old modules *and* keep stale ones out of the way if
that EXTRAVERSION has not been compiled for before. Presumably either
stale modules or failure to copy /usr/src/linux/System.map (in some name
format that applies) to /boot/ have caused your problems (the last
possibility is that you changed support from module to compiled in, and
stale modules need to be deleted). Note that there are a few default
name patterns that System.map is searched for under, as well as paths,
so if you fail to name one specifically, then every compiled kernel will
look for the more generic name "System.map", which will fail for every
kernel except the one it was compiled under. Specific naming with
EXTRAVERSION keeps that from being a problem.

If you do use EXTRAVERSION, this also becomes part of any manual LILO
prompt. If at the LILO prompt you hit tab to see a list of kernel
images, the above scheme would have listed:
2.2.18-May22

You would type that full name in to select that kernel.

D. Stimits, stimits at idcomm.com

> 
> > >>>>> "charles" == charles  <charles at lunarmedia.net> writes:
> >
> > charles> i have netfilter configured as a module in my current kernel
> > charles> configuration:
> >
> > ...snipp...
> >
> > charles> however, when i try to load the module, i get unresolved
> > charles> symbol errors:
> >
> > charles> [~/ipchains] Yes, my master? >modprobe ip_tables
> > charles> /lib/modules/2.4.1/kernel/net/ipv4/netfilter/ip_tables.o:
> > charles> unresolved symbol nf_unregister_sockopt
> > charles> /lib/modules/2.4.1/kernel/net/ipv4/netfilter/ip_tables.o:
> > charles> unresolved symbol nf_register_sockopt
> > charles> /lib/modules/2.4.1/kernel/net/ipv4/netfilter/ip_tables.o:
> > charles> insmod
> > charles> /lib/modules/2.4.1/kernel/net/ipv4/netfilter/ip_tables.o
> > charles> failed
> > charles> /lib/modules/2.4.1/kernel/net/ipv4/netfilter/ip_tables.o:
> > charles> insmod ip_tables faile
> >
> >
> > charles> i am running 2.4.1 and have:
> >
> > ...snipp...
> >
> > charles> can anyone think of reasons why these errors are occurring?
> > charles> thanks -cjm
> >
> > Humm...those symbols are in the netfilter.h include...they should be
> > there. Some things to try:
> >
> > - are you SURE you are running the 2.4.1 kernel you just built?
> >
> > - Might try copying off your .config and then doing a 'make mrproper'
> > and moving the .config back and re-building the kernel and modules.
> >
> > kevin
> > --
> > Kevin Fenzi
> > MTS, tummy.com, ltd.
> > http://www.tummy.com/  KRUD - Kevin's Red Hat Uber Distribution
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> 
> --
> Lindsay Haisley       | "There are no mistakes   |     PGP public key
> FMP Computer Services | only unexpected results" |      available at
> fmouse at fmp.com        |                          |   www.fmp.com/pubkeys
> http://www.fmp.com    |                          |
> _______________________________________________
> 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