Bug 10679 - Module dependencies fail after recompilation of kernel
Module dependencies fail after recompilation of kernel
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-04-09 09:22 EDT by boost
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-04-22 02:46:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description boost 2000-04-09 09:22:37 EDT
After changing some parameters to the kernel (using the config from
/usr/src/linux/configs) (such as scsi emulation and scsi-driver) I
recompiled the kernel and modules (make bzImage modules modules_install),
copying kernel image to /boot, enter it in lilo.conf, copying the
system.map and finaly run lilo and reboot almost all of the modules fail
dependencies. I've tried both removing old modules and doing a fresh
module_install but still tons of dependency problems.

I've upgraded from 6.1 to 6.2
Comment 1 Anonymous 2000-04-13 06:58:59 EDT
I too have had a problem with this. I had to eventually reformat and reinstall
redhat 6.1
Comment 2 Anonymous 2000-04-18 13:50:59 EDT
I can confirm this problem.  I figured I goofed so very carefully deleted the
2.2.14-6.0.1 source and /lib/modules trees, reloaded the source, did the usual
make mrproper xconfig dep clean bzImage modules modules_install.  Then I copied
the new kernel and System.map to /boot with appropriate names, ran lilo and
rebooted.  Same problem.
Comment 3 Anonymous 2000-04-18 17:37:59 EDT
I can confirm this problem.  I figured I goofed so very carefully deleted the
2.2.14-6.0.1 source and /lib/modules trees, reloaded the source, did the usual
make mrproper xconfig dep clean bzImage modules modules_install.  Then I copied
the new kernel and System.map to /boot with appropriate names, ran lilo and
rebooted.  Same problem.
Comment 4 Doug Ledford 2000-04-22 00:42:59 EDT
Did you remember to remake the initrd image in the /boot directory with the new
modules before rerunning lilo and rebooting the system?  If you don't perform
that step, then the initrd image will attempt to load modules from the stock
kernel instead of your newly compiled kernel and they will fail as you describe.
Comment 5 Doug Ledford 2000-04-22 02:46:59 EDT
As an additional item, when changing kernel options and recompiling, you very
well may need to run the command:

rm /usr/src/linux/include/linux/modules/*

in order to force the make process to rebuild the symbol versions with the new
values.

I'm closing this bug since if you remove the files as indicated above and add
the remaking of the initrd image to the other steps listed above then you should
have a working kernel.  I would also suggest that you make sure to use a
different kernel version string than the default one.  I typically add -custom
to the end of the EXTRAVERSION string in the file /usr/src/linux/Makefile
Comment 6 Anonymous 2000-04-24 00:16:59 EDT
I didn't USE an initrd image...disabled the initial ramdisk support, deleted
/usr/src/linux, untarred the kernel source there, moved modules 2.2.14-whatever
to 2.2.14-whatever-old and then recompiled with version symbols.  I can do this
in redhat 6.1 with absolutely no problem, BUT on RedHat 6.2 it would fail not on
compile, not with running lilo, but on boot.  I've ran the EXACT same kernel
config script and exact same steps in redhat 6.1 and produced a perfect working
kernel.
Comment 7 liondatasystems 2000-05-28 08:36:59 EDT
I have had the same experience.
When compiling the kernel from the RedHat 6.2 installation CD, I cannot compile
a kernel without initrd support anymore, whereas this is perfectly possible with
the standard 2.2.14 kernel. What did RedHat do that initrd is now mandatory?
Comment 8 Jed S. Baer 2000-08-17 17:35:07 EDT
Man, I wonder that the problems really were. If anyone is still looking at this
thread, what errors do you get on modprobe/insmod? I get unresolved symbols for 
best_memcopy, best_memset, and a couple of others - all the same .c file - 
best_config.c (I think - I'm not at home just at the moment). Seems to me the
problem is in make xconfig not setting CONFIG_X86_CPU_OPTIMIZATIONS.

I anyone knows whether initrd is really required for correct module symbol
resolution, I'd like to hear about it. (e-mail OK)

Thanks,
jed
Comment 9 Rob McMillin 2000-08-27 17:02:56 EDT
I had this problem and fixed it -- please see bug 11844.

Note You need to log in before you can comment on or make changes to this bug.