If you have an older machine with a slower processor it can take several hours to build a Debian kernel image. (It is possible to build your kernel on a faster machine and install it on the slower machine, but I won't cover that here.) I built a kernel 2.4.18 package on my high-speed low-drag 166 MHz Pentium and it took about 1 hour 40 minutes. That was using my configuration. Using Debian's kernel 2.4.18-bf2.4 configuration, it took 4 hours 45 minutes on the same machine. On a 1GHz Pentium III the same packages built in 9 and 23 ½ minutes, respectively.
To build the kernel you'll invoke "make-kpkg", a script which automates and replaces the sequence "make dep; make clean; make bzImage; make modules". Take a few minutes and read over the manual page for make-kpkg.
make-kpkg is part of the "kernel-package" package. Its documentation is located in /usr/share/doc/kernel-package/. |
The make-kpkg command line can be complex and at first intimidating. Its basic syntax is
make-kpkg <options> <target>
Your target will be "kernel_image". Let's examine two of the more important and common options, "--append-to-version" and "--revision".
The first option lets you specify an addition to the kernel version, which then becomes part of the kernel's name. You may use alphanumeric characters, "+" and "." (period or full stop); do not use underscore "_".
Here's the kernel I'm running now:
bash:/usr/src/linux$ uname -a bash:/usr/src/linux$ Linux sirius 2.4.18.030309 #1 Sun Mar 9 22:15:39 EST 2003 i586 unknown unknown GNU/Linux |
I used "--append-to-version=.030309" (note the leading ".") when I built the image for this kernel. It's shorthand for "2003 March 09", and it's my way of distinguishing this kernel from other 2.4.18 kernels (such as kernel 2.4.18.020724 which I built on 2002 July 24).
You should avoid using --append-to-version values such as "-686", "-K7", and "-sparc". They are commonly used for Debian pre-compiled kernels. |
Kernel modules live in subdirectories of /lib/modules; each kernel has its own subdirectory. Every time you install a kernel image with a new name, the package installer creates a new subdirectory of /lib/modules to hold its modules.
This means that by using a new value for --append-to-version each time you build a kernel image, you can ensure that the new kernel will have a new name, and that its modules won't conflict with those of other kernels.
If you install a kernel with the same name (the same version and --append-to-version) as an already-installed kernel, installing the new kernel package will overwrite the old kernel and its modules. You will be warned and offered the chance to abort. Take it. Use another value for --append-to-version and rebuild. |
Another make-kpkg option is "--revision", which affects the name of the Debian package itself but not the kernel name. As with --append-to-version, you may use only alphanumeric characters, "+" and ".". Do not use underscores "_". If you do not supply a value for --revision, make-kpkg will use "10.00.Custom".
Using different values of --revision will not prevent conflicts between kernels with the same name.
You will not be using --revision in this tutorial.
Debian kernel-image file names have the form
kernel-image-(kernel-version)(--append-to-version)_(--revision)_(architecture).deb
The package name is everything before the first underscore. Here is a partial list of my kernel packages:
bash:/usr/src$ ls kernel-image-2.4.18.030309_1.0_i386.deb kernel-image-2.4.18.030320_1.0_i386.deb kernel-image-2.4.18.030320_10.00.Custom_i386.deb |
Now you can see why underscores are not allowed in make-kpkg options — they separate the elements of package names.
I have two kernel names: 2.4.18.030309 and 2.4.18.030320. I can install both without worrying about conflicts.
I have two revisions of kernel 2.4.18.030320: revision 1.0 and revision 10.00.Custom. If I install either of these kernels and later try to install the other I will get a warning about conflicting kernels/modules. If I continue I will overwrite the already-installed kernel and its modules.
I recommend using a different --append-to-version value for each kernel you compile, and letting make-kpkg assign the default revision. Date-based values work for me, but you are free to invent your own scheme.
Please read /usr/share/doc/kernel-package/README.gz if --append-to-version or --revision is unclear, or if you plan on using options different from the ones I suggest. (One way to do this is "zcat README.gz | most".) Ignore the discussions of flavours and epochs until you are more familiar with make-kpkg and with Debian packages generally; they are not likely to be useful to you now. |
When you added yourself to the src group you made it possible to do most kernel-package work with normal user privilege. However the files that are part of a kernel package (like the kernel and kernel modules) will be owned by root and run with root privilege; they must be created with root privilege.
Using fakeroot you can start make-kpkg as a normal user, and most of the job will be run with normal permissions. Near the end of the job, fakeroot will simulate a root environment to create the kernel-image package.
The manual page for make-kpkg describes one way to use fakeroot; we will use the simpler method of putting "fakeroot" at the beginning of the make-kpkg command line, like this:
fakeroot make-kpkg <options> <target>
Finally! The time has arrived — you're ready to make the kernel image.
bash:/usr/src/linux$ fakeroot make-kpkg clean |
Then do:
bash:/usr/src/linux$ fakeroot make-kpkg --append-to-version=.030320 kernel_image |
Now all you can do is wait for the computer to finish. Take a few minutes off and enjoy yourself while the computer does its fair share of the work.