Re: Compiling same kernel
On Sat, Jun 23, 2001 at 01:31:26AM +1000, Aquila wrote:
> It is a little different, Debian has this package called
> "kernel-package" (apt-get install it) which contains a script called
> "make-kpkg" to create debian packages from kernel source.
Yes, I fully agree. Kernel-package is great. Please install it and read
the documentation, which has a list of all the reasons why you want to
use kernel-package, so I do not have to post a very large email. :-)
In short: with kernel-package, you can compile a linux kernel and it
then becomes a debian package that can be installed (and uninstalled)
cleanly and correctly with dpkg. It is the best thing since sliced
bread and the debian menus system (package menu).
> The usual procedure is this:
This looks good. But I will still add some comments, just to show that
there's more than one way to do it. For one, you are doing this as root
and there is no need for that at all, so it can be avoided.
> - download the kernel source for 2.2.17
> - unpack it into /usr/src/linux-2.2.17
I would:
$ mkdir -p ~/src/linux/v2.2.19 && cd $_
# mkdir and cd to it (shell tricks)
$ wget http://www.kernel.org/pub/linux/kernel/v2.2/linux-2.2.19.tar.bz2
# .gz is 3.5 megabytes bigger than .bz (18.4 - 14.8)
$ bzcat linux*bz2 | tar xf -
# tar bz2 switch change hell, at least this always works
# bin/traceroute luvvers, think about it.
> - create symlink from /usr/src/linux-2.2.17 to /usr/src/linux
> (housekeeping)
There is no need for that, you can make a kernel-headers package along
with the kernel-image. The kernel-headers .deb will contain what you
are trying to put up manually. And strictly speaking, there is no need
at all to put these headers in a standardised place, because they are
not to be used in that way anyway.
All your kernel headers come with libc, because they're not supposed to
change. Any software that needs moving target kernel interface header
definitions in order to build, has to keep its own snapshot copies of
such definitions for itself. FAIK this is the current concensus by the
linux-kernel people.
Now, another case is kernel modules that do not come with the linux
kernel source proper, but will still be intricately linked to intimate
interfaces of your running kernel. For that reason, you want to keep
a fully configured and make dep'ped version of your linux source tree
around, so you can use it to build external modules in it.
In practice, you don't need even that, you just want to build the
kernel-image and all external modules debs (see kernel-package docs)
at the same time. You will likely not want to change one without also
updating all the others. So all, that you really need to keep around
between recompiles, is the config. Which is also done automatically
by kernel-package, it puts it in the kernel-image.deb, which unpacks it
into /boot when you install the deb. Nifty, eh? And it does the same
for the System.map file. And it updates and runs your lilo or grub
from the postinst of the kernel-image.deb you create. All of that,
automatically.
> - do your sound card patching or whatever you wanted to do here
Lets assume that this is not the case and that the sound driver is in
Linus' kernel. To keep things simple. :-)
> - cd /usr/src/linux
$ cd linux
$ cp /boot/config-2.2.18 .config
# used kernel-package for last one, hw did not change.
$ make oldconfig
# asks only new / altered questions
> - make menuconfig (or xconfig or whichever you prefer)
> - make-kpkg kernel-image
$ fakeroot make-kpkg --revision 3:`hostname`.1.0 kernel-image kernel-doc
Fakeroot, from the fakeroot package, is what allows you to build debian
packages as non-root user. Other things to note are:
I explicitly set a version and put letters in first. The reason is that
the maintainer of the official debian kernel-image packages will use only
versions that begin with the kernel version number. Letters compare to
be bigger than numbers so my version will always appear 'newer' to dpkg.
There is a pitfall though, because this is not the complete story :-(
Dpkg will recognise so called "epoch numbers" in a version string, the
'3:' part in the above example. This is intended to be an escape hatch
for in case the regular versioning gets messed up for whatever reason.
The epoch overrides the normal version numbering scheme.
Once in a while, the official kernel-image packages' version may get
messed up and the maintainer adds an epoch, to which you can do nothing.
You are not even forewarned. All that can be done, is to preempt this,
by always using a high epoch number on your homebrew packages. The epoch
number will be in the deb, but will not show in the filename, btw.
Note that IF you were compiling external modules, the invocation of
make-kpkg would have been something along the lines of:
$ MODULES_FOO_VAR=things_to_pass make-kpkg kernel-image modules-image
Getting this right exactly is left as an excercise to the reader. :-)
> this would create kernel-image-2.2.17-???.deb in /usr/src
> Then just dpkg -i the package.
And maybe dpkg -r some old kernel-image and all associated files that
you do not need anymore (and you can always keep its .deb around, for
in case).
Also a point of note IMHO is to check /etc/lilo.conf, / and /boot/
and to run "lilo -v -v". Even though make-kpkg puts a postinst in the
kernel-image deb that tries its best to do all of this automatically,
I don't trust any script to make my machine unbootable in a fully
automated fashion. So I always doublecheck. TIMTOWTDI and YMMV.
To sum things up, kernel-package is definately the finest cookie-cutter
tool debian ever had.
Cheers,
Joost
Reply to: