Re: Building kernel modules for stock kernels is a hell of a job!
Manuel Bilderbeek <manuel@msxnet.org> writes:
> After having worked with Debian testing for about 2 years, I'm getting
> fed up with the seemingly unnecessarily complicated way of building
> kernel modules for the stock kernels.
> 1) install the kernel source for the kernel,
> e.g. kernel-source-2.4.21
Since you're singling out lm-sensors here, I can tell you that
lm-sensors-source does build fine against the correct kernel-headers
package; the "normal" binary package build-depends on a kernel-build
package to get all of the kernel-headers, and uses those without any
particular magic.
> 5) apt-get install [modulename-source] (sometimes -src),
> e.g. lm-sensors-source.
>
> 6) this should give [modulename].tar.gz in /usr/src; extract it: tar
> xzvf [modulename].tar.gz
> now, the source is in /usr/src/modules/[modulename]
At this point, I think what I would tell you to do is (untested):
cd $MODULE_LOC/$modulename
debian/rules kdist-image KDREV=2.4.21-4 KVERS=2.4.21-4-k7 \
KSRC=/usr/src/kernel-headers-2.4.21-4-k7 \
KMAINT="Your Name" KEMAIL="you@example.com" \
APPEND_TO_VERSION=-4-k7 ROOT_CMD=fakeroot
which will produce the binary package you're looking for in /usr/src.
This is just using the interface required by kernel-package.
> 9) install the just built package(s) with dpkg -i [package_name]
> now the kernel modules should be in the right dir in /lib/modules and
> modprobe (or modconf) can find them.
> - If you have just installed a new kernel-image package (i.e. a new
> stock kernel), you need to do everything from the start *after*
> booting this new kernel
You shouldn't need to. (Though you go through a little more effort to
get the right .config file.)
> - In my experience, if you forget the export of step 7, you have to
> wipe your whole kernel source tree and start at step 2. I know I'm
> supposed to do a make-kpgk modules clean, but that didn't do the
> trick;
'rm -rf /usr/src/modules' is often quite theraputic for odd problems
like this. Screwing up --append-to-version using kernel-package has
kind of unfortunate side effects for recovering. :-/
> People, stock kernels are very comfortable, but building modules for
> them is not! Please tell me what I did wrong, or make the procedure a
> lot easier! (The latter especially applies to the maintainers of that
> NVIDIA package...)
>
> Luckily, David Z. Maze has the lm-sensors as binary package in
> unstable nowadays... :) (Although not yet for 2.4.21...)
In some ways, doing this feels a lot like a very slow game of
Whack-A-Mole. The process goes something like this:
(1) Notice that Debian kernel 2.4.21-1 exists.
(2) Install kernel-build-2.4.21-1. Change debian/rules to reference
the right kernel.
(3) Actually rebuild the package. This winds up taking quite a long
time for me, particularly since there are seven different kernel
flavors and I'm foolishly doing the build over AFS over a cable
modem. (Should probably fix that. :-)
(4) Upload.
(5) Wait for ftpmaster, since these are all new packages.
(6) Notice that Debian kernel 2.4.21-2 exists.
(7) ftpmaster accepts lm-sensors-2.4.21-1-*, which depend on
kernel-image-2.4.21-1-*, which is no longer in the repository.
(8) Go to 2.
It's also a bit frustrating to look at cross-platform compatability,
and realize that the magic to get things built is just going to be
different on each platform, since the platform-specific kernel
packages are all different. Plus getting stock kernel modules built
is presently entirely in the hands of the module maintainers, and the
glue code in debian/rules to actually do that is kind of groady.
I suspect for unstable, there's just not a lot to be done. For sarge,
we should probably pick a kernel and a kernel ABI (or sets thereof)
and not change it, so that packages that provide prebuilt kernel
modules can do that more reasonably.
--
David Maze dmaze@debian.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell
Reply to: