The Answer Gang

Modules cannot load with kernel recompile

From Michael Hansen

Answered By Ben Okopnik, Chris Gianakopoulos

Hello TAG--

I have attempted recompiles of RH 6.2 several times, and have encountered similar problems every time. After recompiling the kernel, the new kernel will boot correctly but some modules don't load because of dependencies on other modules that are not loaded.

Just now, I have encountered a more fatal problem--no modules will load at all. When I try to "insmod" or otherwise load the module, it lists symbols that it cannot resolve. One in particular that I checked out--best_malloc--is a symbol that appears to be in the kernel itself. Every module seems to need it, and none can find it.

The modules themselves appear to be in the right place. ksyms -a appears to see the symbols that the modules are looking for, when those symbols aren't in other modules that aren't loaded.

So, two questions. (1) Is there a simple utility/series of steps for compiling and loading all modules and their dependent modules, avoiding potential problems in xconfig associated with not specifying all of the proper module dependencies, and (2) do you know why this latest recompile doesn't let any modules load at all due to external symbols that it can't find in the kernel?

Any help is appreciated.

[Ben] Just a guess, off the top of my head - are you doing the "make modules" and the "make modules_install" steps? Here is the complete list of steps for a "from-scratch" kernel compile for my own system:

make mrproper # Not necessary for a recompile
make [config|menuconfig|xconfig] # Choose one; xconfig is easiest
make dep
make clean
make [zImage|bzImage] # I always use bzImage these days
make modules
make modules_install

Save the old kernel (I keep a "current" and an "old" copy) -

mv /boot/vmlinuz-2.2.17 /boot/vmlinuz-2.2.17-old

Put the new image in /boot and rename it -

cp /usr/src/kernel-source-2.2.17/arch/i386/boot/bzImage /boot/vmlinuz-2.2.17

I have symlinks, "/vmlinuz" and "/vmlinuz-old", to "/boot/vmlinuz-2.2.17" and "/boot/vmlinuz-2.2.17-old";

all that remains, since my "/etc/lilo.conf" is properly set up, is to run "/sbin/lilo":

Odin:~# lilo
Added Linux *
Added OldLinux
Added dos
Odin:~#

Save the old system map -

mv /boot/System.map /boot/System.map-old

Copy the new one -

cp /usr/src/kernel-source-2.2.17/System.map /boot

Save the old configuration file -

mv /boot/config-2.2.17 /boot/config-2.2.17-old

Copy the new one -

cp /usr/src/kernel-source-2.2.17/.config /boot/config-2.2.17

Obviously, all of the above can (and should) be put in a shell script with some options on what to run.

Done.

Note that if you try to run a new kernel with old modules (or vice versa, by not installing the new kernel properly), you'll get just the kind of errors that you're reporting.

Regarding not making the modules... I did go through the process of

and it appeared to copy the right object files in the right directory tree, and compiled cleanly.

Is it possible that the symbol table used to resolve external references between modules and the kernel has been corrupted?

[Chris] Hey Mike,

This may or may not help you. I use SuSE 6.4 as my distribution (2.2.14 kernel). I too have to go through all of that cool build stuff. One thing that the SuSE distribution says to do. I have to copy /usr/src/linux/System.map to the root directory (/). That file contains kernel symbols which are needed by the modules to launch kernel functions correctly. I know that Linux is Linux, but, I must be careful when passing this information. It applies to the SuSE 6.4 distribution; maybe it applies to your Red Hat distribution.

Let someone with more Linux knowledge answer your other questions.

Chris G.

Thx for the interest...should have laid out the entire process that I followed for compiling but didn't because I don't have linux on the net, needed to switch to Windows to send e-mail...

Still stumped. Something is really broken. I must be doing something wrong to not have the kernel compile right out of the box. Just can't find it. Followed all directions to the letter.

[Ben] It's not necessarily you doing anything wrong. The compile-and-install procedure, as I have laid it out, is somewhat tedious (hence, my suggestion of a shell script) but not difficult - if you follow it step by step and it still doesn't work, you need to look at other things.

Where did you get the source? If possible, you should use the package that your distro producer has - they may have done some quirky stuff in the setup that needs to be there for it to work properly. In theory, you should be able to just download it from kernel.org, compile, and run - but people like RedHat have so many things already configured in that I'd rather not guess. Somehow, (mirabile dictu!) I've avoided doing a RedHat kernel recompile, and Debian has never cared where the source comes from, but it's a possibility.

Try "disabling" the old modules by renaming the directory that contains them -

mv /lib/modules/2.2.17 /lib/modules/2.2.17-old

Then, after doing the "make modules_install", check in "/lib/modules" to make sure that you have a new "2.2.17" directory, that there is a reasonable directory tree under it ("block", "fs", "misc", "net", etc.), and that the modules that should be there are indeed there. (Obviously, you'll have to change the numbers for your own kernel version.) I seem to remember having a problem, in the past, where "modules_install" failed rather quietly and did not create the directories or copy the modules... I'm trying to recall the fix, but the best I can come up with is that it had something to do with the Makefile syntax in "modules_install". Whatever it was, moving the old modules directory made the error obvious, and the fix wasn't a difficult one.

Whenever I've found myself in this kind of a maze of little passages, all alike, The Canonical Fix that always worked was a complete, from-scratch (meaning, including "mrproper" and "clean") compile, perhaps including deleting the existing source tree and re-unpacking the tarball or package. If that doesn't work, I'd either suspect the provenance of the source, or I'd write to the kernel maintainers with a complete description.

Of course, if you're building an experimental kernel, you're on your own. Subscribing to a developer's list might be the only answer.

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 64 of Linux Gazette March 2001

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

	1   2   3   4   6   7   9
	11   12   15   16   18
	20   22   24   25   26   28   29