Bug 76216 - New kernels always search for old modules
Summary: New kernels always search for old modules
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: initscripts
Version: 8.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-10-18 10:26 UTC by Sensei
Modified: 2014-03-17 02:31 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2002-10-23 09:13:09 UTC
Embargoed:


Attachments (Terms of Use)

Description Sensei 2002-10-18 10:26:51 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
After installing a new kernel (from 2.4.18-14custom shipped with RH8 to
Kernel.org kernels), at the first reboot the kernel loader searches always for
the old kernel modules shipped with the RH 8 kernel. Moreover, the symbolic link
System.map pointing to System.map-MYKERNEL changes at the first reboot in
System.map-2.4.18-14 (the original RH 8.0 installation).

This causes hangups (on my system, always at reboot and poweroff).

Version-Release number of selected component (if applicable):
Any

How reproducible:
Always

Steps to Reproduce:
1. Compile a kernel (in menuconfig it's horrible to see)
2. Install the kernel, making symbolic links so System.map and vmlinuz
3. Reboot
4. Look at the output
5. Try to reboot or poweroff

Actual Results:  
1. Failed to load come 2.4.18-14 (RH original installation) modules, 
   even if you didn't want them
2. System.map-YOURKERNEL changes to System.map-2.4.18-14 (RH original
   installation)
3. Hangups, crashes.

Expected Results:
Load the kernel and modules which you specified, from your kernel version, not
the redhat one.

No hangups.

Possibility to use other kernels different from the one shipped with the
original installation.

Additional info:

My system is:

ASUS A7V266-E
512 Mb DDR
ATA-100 41 Gb HDD
LG CDR/RW Burner 16-10-40
LG CD/DVD-ROM Reader
Abit Siluro GeForce2 MX GPU

Comment 1 Bill Nottingham 2002-10-18 16:15:26 UTC
Are you sure that your kernel was compiled correctly? Did you install all the
modules from it?

Comment 2 Sensei 2002-10-19 09:07:40 UTC
Yes, make clean, dep, bzImage, modules, modules_install worked properly. I tried
to install the kernel.org 2.4.19: no warnings, no errors... At the first reboot
it showed me some errors about loading modules for 2.4.18-14 (HID, USB keyboard,
USB mouse) which I did not compile in this kernel.

Comment 3 Bill Nottingham 2002-10-21 04:46:56 UTC
If it is trying to load modules out of the 2.4.18-14 directory

a) you miscompiled your kernel somehow (did you run make mrproper, or just make
clean?)
b) you somehow booted a different kernel.

Comment 4 Sensei 2002-10-21 10:32:51 UTC
a) No, no miscompilation. I just ran make clean. Make mrproper is not so
different from clean (am I right?).

b) No, I'm not a newbie! ;)

Comment 5 Bill Nottingham 2002-10-21 17:49:16 UTC
No, you need to run make mrproper; the kernel-source package ships with symbols
by default for compiling modules against the shipped kernel. Failure to run make
mrproper can run into miscompiled modules.

Comment 6 Bradley 2002-10-23 02:58:38 UTC
I had this happen to me, too.

The problem is that the kernel-source package ships with a prebuilt version.h
file for a uname w/o the 'custom' extraversion.

If failing to run |make mrproper| before compilation results in miscompiled
modules, and the kernel-source package's job is basically for recompiling the
kernel, why isn't this done before packaging?

Comment 7 Sensei 2002-10-23 09:13:02 UTC
The same problem appears compiling an official kernel. I tried to boot with
2.4.18 and 2.4.19, but the kernel module loader always searches for 2.4.18-14.

Now I installed from the RH network the kernel 2.4.18-17.8.0-athlon and it works
fine. But why I can't boot from a self-compiled kernel... who knows... ;)

Comment 8 Bill Nottingham 2002-10-23 15:06:54 UTC
The reason that module symbols are included is for compiling external modules
against the running kernel.

senseiwa: the problem you have, since it also appears with kernels you
compile from upstream sources, it *sounds* like you have bootloader
configuration issues, and you're actually rebooting the old kernel. For example,
if you're running lilo, you need to add the proper stanza and re-run lilo, etc.

AFAICT, this does not represent any initscripts problem.


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