Bug 121132 - kernel-source insufficient to build modules against packaged kernels
kernel-source insufficient to build modules against packaged kernels
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-04-17 15:39 EDT by Nils Philippsen
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-04-19 09:41:45 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 Nils Philippsen 2004-04-17 15:39:21 EDT
Description of problem:

When trying to build modules for a packaged kernel, building the
modules fails due to a missing file Modules.symvers:

[...]
nils@gibraltar:~/redhat/BUILD/madwifi-20040410/linux> make
EXTRAVERSION=-1.326 SUBDIRS=../wlan modules
  CC [M]  ../wlan/if_media.o
  CC [M]  ../wlan/rc4.o
  CC [M]  ../wlan/if_ieee80211subr.o
../wlan/if_ieee80211subr.c: In function `ieee80211_recv_beacon':
../wlan/if_ieee80211subr.c:2934: warning: comparison is always false
due to limited range of data type
../wlan/if_ieee80211subr.c: At top level:
../wlan/if_ieee80211subr.c:2756: warning: `ieee80211_send_tspec'
defined but not used
  CC [M]  ../wlan/if_ieee80211wireless.o
  LD [M]  ../wlan/wlan.o
  Building modules, stage 2.
  MODPOST
/home/nils/redhat/BUILD/madwifi-20040410/linux/Module.symvers: No such
file or directory
make[1]: *** [__modpost] Error 134
make: *** [modules] Error 2
nils@gibraltar:~/redhat/BUILD/madwifi-20040410/linux>
[...]

Note that .../madwifi-20040410/linux is a tree of symlinks into
/usr/src/linux-2.6.5-1.326 (after "make oldconfig" and "make
prepare-all"). Apparently Module.symvers should get generated from
vmlinux's symbols when compiling the (packaged) kernel. Perhaps the
various Module.symvers should be kept for later use like the various
.config files in config/kernel-*.config.

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

kernel-2.6.5-1.326
kernel-source-2.6.5-1.326

How reproducible:

Easy: Try to build a module as described against
kernel-source-2.6.5-1.326.
  
Actual results:

Build breaks with complaints about missing Module.symvers.

Expected results:

Module gets built without errors.
Comment 1 Nils Philippsen 2004-04-17 15:40:28 EDT
NB: Faking Module.symvers (like in "touch Module.symvers") didn't work
out, scripts/modpost wouldn't eat it.
Comment 2 David Hollis 2004-04-17 17:11:36 EDT
I found that if I went into /usr/src/linux-2.6.5-1.326, copying the
appropriate config from configs to .config and ran 'make',
Module.symvers would be created (after rebuilding the kernel of
course).  I then had to copy that to /lib/modules/2.6.5-1.326/build so
I could build my external modules.  So far, so good.  Looks like the
Module.symver for the various builds needs to be shipped in the kernel
package.
Comment 3 Arjan van de Ven 2004-04-17 18:07:02 EDT
kernel-source is 100% ansolutely not intended for building modules
against. 

Yes Module.symvers is missing in 326 but whatever module you're trying
to build is severly broken in the makefile if it tries to use the
stuff in kernel-source.
Comment 4 Nils Philippsen 2004-04-18 07:44:30 EDT
I see.

In that case, how am I supposed to build modules for different
(sub)arches or variants, e.g. if I build on a UP system, must I
install the kernel-smp packages as well? How about i386 packages --
when I can't install both i386 and i686 kernels on the same machine?

With the old scheme of building from kernel-source, I could just copy
the source tree, use the appropriate configs/kernel-config-* files to
build modules for i386, i686, athlon (for 2.4) and for UP and SMP
regardless of what specific subarch and variant the kernel currently
running was. Is there any way to achieve the same with the new build
scheme?
Comment 5 Arjan van de Ven 2004-04-18 11:50:20 EDT
1) what you describe is rather incorrect for the 2.4 rpm
2) that's no longer possible with the 2.6 rpms; you can only build
modules for the installed rpms now.
Comment 6 Nils Philippsen 2004-04-18 12:53:06 EDT
1) I was referring to 2.6 only.
2) Shall I open a new bug report for this? This essentially makes it
impossible to make packaged builds of "3rd party" modules...
I know you don't like the notion of modules being built outside the
kernel package, but there are a lot of modules not in kernel.org
kernels -- or ours -- that are actually useful and it would be a pain
if we couldn't spare "mere users" the hassle of building these modules.
Comment 7 Arjan van de Ven 2004-04-18 14:10:41 EDT
don't bother opening a new bug.
You need to build such modules against the exact kernel, which means
the kernel needs to be installed. You're probably better of shipping
the (of course full) source and an rpm that somehow builds them on demand.
Comment 8 Warren Togami 2004-04-18 23:10:56 EDT
*** Bug 121094 has been marked as a duplicate of this bug. ***
Comment 9 Warren Togami 2004-04-18 23:12:08 EDT
*** Bug 120944 has been marked as a duplicate of this bug. ***
Comment 10 Andrew Farris 2004-04-19 00:20:08 EDT
Will the future kernel binary RPMs have the Module.symvers file
included in the build directory as expected?  If not, then building
external modules is broken even when the target kernel is installed
and running.
Comment 11 Arjan van de Ven 2004-04-19 02:50:25 EDT
120944 and 121094 are not duplicates of this bug.
Comment 12 Nils Philippsen 2004-04-19 07:46:24 EDT
Re: comment 7, this is a bit unfortunate because then debugging is a
lot harder because you don't have the same binary as the user has.

Would it be possible to put /lib/modules/.../build into a separate
package (say kernel{,-smp}-build-{i386,i686}) -- which wouldn't
require the matching kernel package -- to facilitate building modules
without the need to install the kernel itself (which builds initrds,
clutters /boot/grub/grub.conf, ...)?

I know that these packages would still have the same arch as the
kernel built so in theory it would be a small problem to build for
athlon kernels (which aren't there in 2.6) on an i686 box because rpm
would complain about the wrong architecture, but that could be worked
around with some rpm flags when installing said package.

Would you accept patches that implemented a scheme like this?
Comment 13 Arjan van de Ven 2004-04-19 09:41:45 EDT
No; separate packages bring back a lot of the kernel-source pain and
none of the gain.
Comment 14 Nils Philippsen 2004-04-19 10:53:06 EDT
What about the pain for packagers I outlined above?

To mitigate it, I could think of e.g. having /lib/modules/.../build as
it is in the kernel{,-smp} package and having a separate
kernel-build-%{arch} package for each architecture containing all that
is in /lib/modules/.../build for that architecture under a separate
directory, possibly even a bzipped tarball of it which would only
account for roughly 2.5MB instead of about 32MB per kernel variant at
the moment.

Such packages could then be used for pre-built external modules, which
-- in contrast to something built-on-the-fly -- could actually be QAed
before being let loose on users.
Comment 15 Nils Philippsen 2004-04-19 11:36:38 EDT
To clarify: leave /lib/modules/.../build as they are so building
modules against an installed kernel is as easy as possible, a separate
kernel-build-%{arch} would be an additional package.

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