Bug 121132
| Summary: | kernel-source insufficient to build modules against packaged kernels | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nils Philippsen <nphilipp> |
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | lordmorgul, notting, philip |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-04-19 13:41:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Nils Philippsen
2004-04-17 19:39:21 UTC
NB: Faking Module.symvers (like in "touch Module.symvers") didn't work out, scripts/modpost wouldn't eat it. 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. 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. 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? 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. 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. 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. *** Bug 121094 has been marked as a duplicate of this bug. *** *** Bug 120944 has been marked as a duplicate of this bug. *** 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. 120944 and 121094 are not duplicates of this bug. 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? No; separate packages bring back a lot of the kernel-source pain and none of the gain. 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.
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.
|