This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 109352 - insmod complains about kernel version mismatch when CONFIG_MODVERSIONS = y
insmod complains about kernel version mismatch when CONFIG_MODVERSIONS = y
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: modutils (Show other bugs)
7.3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-06 18:22 EST by Dan Mack
Modified: 2014-03-16 22:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-07 00:34:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Dan Mack 2003-11-06 18:22:07 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617

Description of problem:
We ship a kernel and modules with our product.  Our kernel happens to
be 2.4.19 based with patches and we use a slightly changed version of
the redhat supplied configs/*bigmem config file.

We generate an RPM and a -source rpm for the kernel so that users can
easily build modules against our patched kernel source.

We have CONFIG_MODVERSIONS turned on and all of our modules were built
with these turned on.

If we build a new version of a module against the kernel source which
is installed in /usr/src/linux-2.4, the modules build just fine,
however, insmod acts as if we have CONFIG_MODVERSIONS turned off:

/foo/bar/modules.debug/abcproc.o: kernel-module version mismatch
        /foo/bar/modules.debug/abcproc.o was compiled for kernel
version 2.4.19-22.usi-mack
        while this kernel is version 2.4.19-22.usibigmem.
: insmod abcproc.o failed

True, I gave the kernel in /usr/src/linux-2.4 a different name but
that should not matter when CONFIG_MODVERSIONS is set to y, correct?

I think this is a bug, possibly the result of
modutils-2.4.18-versions.patch which is applied to the virgin modutils
source code.

If I download modutils from kernel.org and build it, their version of
insmod works correctly and my module loads.

I even tried using the latest 2.4.25 version of the redhat-ified
modutils from fedora and I get the same behaviour.

[root@n5 etc]# grep printk /proc/ksyms 
c011d7d0 printk_Rsmp_1b7d4074

[root@n5 etc]# nm /foo/bar/modules.debug/abcproc.o|grep printk       
     
         U printk_Rsmp_1b7d4074

These symbols clearly indicate that CONFIG_MODVERSIONS is in effect so
why is insmod even comparing the version strings on my kernels?

If I rebuild the rpm package without applying the
modutils-2.4.18-versions.patch, insmod works just as good.

I can reproduce this with plain old hello.o as well.




Version-Release number of selected component (if applicable):
modutils-2.4.18-3.7x

How reproducible:
Always

Steps to Reproduce:
1.See above
2.
3.
    

Additional info:
Comment 1 Bill Nottingham 2003-11-07 00:34:50 EST
This behavior was intentional; to warn if the module was built for a
different kernel even if the modversions are the same.

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