This is the Debian GNU/Linux prepackaged version of the Linux kernel.
Linux was written by Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI> and
others.

This package was put together by Simon Shapiro <Shimon@i-Connect.Net>, from
sources retrieved from directories under
ftp.cs.helsinki.fi:/pub/Software/Linux/Kernel/

Linux is copyrighted by Linus Torvalds and others.

   This program is free software; you can redistribute it and/or modify
   it under the terms of the GNU General Public License as published by
   the Free Software Foundation; version 2 dated June, 1991.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   GNU General Public License for more details.

   You should have received a copy of the GNU General Public License
   along with this program;  if not, write to the Free Software
   Foundation, Inc., 675 Mass Ave., Cambridge, MA 02139, USA.

On Debian GNU/Linux systems, the complete text of the GNU General
Public License can be found in `/usr/doc/copyright/GPL'.

INSTALLATION NOTES:

 For the Brave and the impatient:
1% cd <kernel source tree>
2% make config   # or make menuconfig or make xconfig and configure
3% make-kpkg clean
4% make-kpkg -r=custom.1.0 kernel_image
5% dpkg -i ../kernel-image-X.XXX_1.0_<arch>.deb
6% shutdown -r now # If and only if LILO worked or you have a means of
                   # booting the new kernel. YOU HAVE BEEN WARNED!!

 

 Detailed instructions

Firstly, you will need gcc, the libc development package (libc5-dev at
the time of writing), and, on intel platforms, bin86. [If you use the
menuconfig target of make, you will need ncursesX.X-dev, and make xconfig
also requires tkX.X-dev, and other packages these depend on]

Oh, and of course, make-kpkg is part of kernel-package, usually found
in section misc.

Then, remember to change the revision number (using the -revision
option of make-kpkg).  It has been suggested that you renumber the
revision number in such a way that a generic kernel image package will
not override the custom package while using dselect (or dpkg
-BORGiE). You may also do this on the fly by setting the
DEBIAN_REVISION environmental variable.

The revision number (the argument supplied after the --revision flag)
has certain constraints: it may contain only alphanumerics and the
characters + . (full stop, and plus) and should contain a digit.
NOTE: No hyphens allowed. (Look at Chapter 5 of the Programmers manual
for details)

This is because dpkg imposes an ordering on version numbers, so that
it can tell whether packages are being up or downgraded and so that
dselect can tell whether a package it finds available is newer than
the one installed on the system.

I've found that using a two-level scheme where the major level starts
with a letter nicely does the job, (debian=custom.Y, so the image package
become kernel-image-X.X.XX-custom.Y.deb), and dselect and dpkg -BORGiE
will refuse to downgrade to a generic kernel (don't give the BOG
arguments to dpkg if you actually do want to downgrade later).

You may also place long term directives (like your name and email
address) in the file /etc/kernel-pkg.conf. Putting your name and
address in that file is a good idea, to remind you that this is not an
official package, unless, of course, you happen to be the maintainer
(Hi Simon). The file /etc/kernel-pkg.conf is actually a Makefile
snippet included during the kernel packages build process, and hence
you may put any legal Makefile directive in that file (just make very
sure you know what you are doing ;-)

The version number is deduced from the kernel Makefile directly. to
ensure that the version numbers are in sync(1), so you don't have to
worry about that.

To generate a new kernel image, just run
% make-kpkg clean
% make-kpkg -r=custom.1.0 kernel_image

This will create a default kernel image (as in the image package or
available on the boot disks.  The kernel image package produced will
offer you a chance to create a bootdisk, or to run lilo, but the
default is not to do either, and you may choose to ignore these
friendly overtures by the postinst.
 
If you want a custom kernel, you may generate a config file by any of
these methods (just follow the directions).
% make config          # Boring old tty based method
or
% make menuconfig      # curses based menu driven method (uses color if 
                         you have any)
% make xconfig         # An X window system based method -- make sure
                         you are running X windows when you call this.
All these methods ultimately generate a .config file.  If you already 
have a .config file, just copy it to this directory, and you are go.

With a custom .config file in place (created as above) run again:
% make-kpkg clean
% make-kpkg -r=custom.1.0 kernel_image


To create a source or header package, run
% make-kpkg clean
% make-kpkg -r=custom.1.0 kernel_source
% make-kpkg -r=custom.1.0 kernel_headers
Note: You only need one of these.

Or if you want to generate the whole package, 
% make-kpkg --revision=custom.1.0  --pgp="Your pgp ID" buildpackage

A note on LILO: the kernel-image install-scripts arrange to have
/vmlinuz and /vmlinuz.old point to the latest kernel image and the
next most recent one, respectively.  You may choose to have LILO take
advantage of this by putting image = /vmlinuz and image = /vmlinuz.old
lines in your lilo.conf (please read documentation on LILO for
details)

Conversely, people who wish to tightly control the versions in
lilo.conf (believe me, people, this gets to be a pain in the neck
fast) can use image = /boot/vmlinuz-X.X.XX.

So that loadlin people don't feel left out, all this talk about LILO
does not mean to ignore loadlin, you can use the generated
kernel-image just as easily (simply ignore the fol-de-rol with sym
links in /). for instance, you could:

 [1]% dpkg -BRGiE kernel-image-X.X.XX,
        and then
 [2]% cp /boot/vmlinuz-X.X.XX <place where loadlin needs image>
 [3]% echo '' > /boot/vmlinuz-X.X.XX

        So you don't have the image taking up space, but still leave a
target for the /vmlinuz symlink.

Have fun,

	Manoj Srivastava

Foot note 1:
  For an explanation on why this synchronization is required, consider
  this. The kernel knows what version it is, as given in the kernel
  Makefile as the variables VERSION, PATCHLEVEL, and SUBLEVEL. It will
  look for the modules in /lib/modules/$VERSION.$PATCHLEVEL.$SUBLEVEL.
  The debian scripts think they know what the kernel version is, as
  given in the Debian file rules as the variable v (near the top). It
  then proceeds to put the modules in /lib/modules/$v.  So, it is
  essential that the kernel (Makefile) and the Debian script (rules)
  agree about the version number, or the kernel will never figure out
  where the Debian scripts hid the modules. So change the version
  number in the file rules (v = X.X.XX) to be the same version as
  given in the kernel Makefile (this will be
  $VERSION.$PATCHLEVEL.$SUBLEVEL).

-- 
Manoj Srivastava                           <srivasta@debian.org>
PGP Key ID: 1024/C7261095 
Key fingerprint =  CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E 
