====== Building kernel deb with TuxOnIce support ======

This guide is now replaced by //[[debian:kerneldeb]]//.

This is an outline of how to build a TuxOnIce enabled kernel deb package **using debian's deb packaging** (instead of the kernel's own).

Variables: Example variable values below:\\
  KVER = 2.6.32
  REV = 3-amd64+toi
  EPOCH = 2

  * Download sources of latest kernel, kernel building stuff and TOI interface ((Replace ''$KVER'' with the appropriate kernel version)) <code># apt-get install linux-source-$KVER build-essential kernel-package fakeroot tuxonice-userui</code>
  * Download TOI patch for that kernel version from http://www.tuxonice.net/, e.g.: <code># cd /usr/src && wget http://www.tuxonice.net/downloads/all/tuxonice-3.1-for-$KVER.patch.bz2</code>
  * Prepare to build as normal user ((Here my user is in the ''src'' group)) ((Replace ''$REV'' with the value passed to ''make-kpkg'' in ''--append-to-version'')) <code># cd /usr/src
# mkdir linux-headers-$KVER-$REV
# chgrp src linux-headers-$KVER-$REV
# chmod g+rwxs linux-headers-$KVER-$REV</code> **Important** The package will contain a couple symlinks to the build location (its //real// path), so use an appropriate directory name under ''/usr/src''. Using ''headers'' will allow a ''linux-headers'' package to fill in the links. \\ **From hereon run as normal user**
  * Uncompress ((From here on run as normal user)) <code>$ cd /usr/src
$ tar -jxv --strip-components=1 -C linux-headers-$KVER-$REV -f linux-source-$KVER.tar.bz2</code>\\ (Alternative, more explicit version:) <code>$ cd /usr/src/linux-headers-$KVER-$REV
$ tar jxvf ../linux-source-$KVER.tar.bz2
$ mv linux-source-$KVER/* . && rmdir linux-source-$KVER</code>
  * Apply patch <code>$ cd linux-headers-$KVER-$REV
$ bzcat /usr/src/tuxonice-3.1-for-$KVER.patch.bz2 | patch -p1</code>
  * Import Debian configuration ((Accept defaults for any prompted option if you are unsure)) <code>$ cp /boot/config-`uname -r` .config
$ make oldconfig</code>
    * TOI Related configuration uses the «''TOI_''» prefix. Accept all default except for ''TOI_USERUI_DEFAULT_PATH'', set to ''/usr/lib/tuxonice-userui/tuxoniceui_text'', which is provided by ''tuxonice-userui''
    * Boot logo can be enabled with ''CONFIG_LOGO=y'' in ''.config''. Package ''linux-patch-debianlogo'' contains a debianized version.
      * Debian logo patch: <code>zcat /usr/src/kernel-patches/diffs/debianlogo/debian-logo-2.6.$CLOSESTVERSION.gz | patch -p1</code>
        * If it fails revert by changing ''patch'' to ''patch -p1 -R''
    * At this point re-configuring and disabling features absolutely unneeded in the foreseeable future might shave a lot of compile time <code>$ make menuconfig</code> (my [[Linux:KernelCFG|list]])
  * Build with ''make-kpkg'', here's my preferred options ((replace ''$X'' with the debian revision (e.g. 2.6.32-**3**-amd64); replace ''$ARCH'' with architecture name (e.g. 2.6.32-3-**amd64**); replace ''$EPOCH'' with 2 to prevent automatic upgrades; replace ''$NCPUS'' with the number of CPUs/cores/threads to use for building)): <code>$ make-kpkg --rootcmd fakeroot --revision $EPOCH:$KVER~$X+toi --append-to-version -$X-$ARCH+toi --arch_in_name --initrd -j $NCPUS kernel_image</code>
    * E.g., if architecture is ''amd64'' and the corresponding Debian kernel is 2.6.32-3-amd64, for a dual-core building machine, this will be: <code>$ make-kpkg --rootcmd fakeroot --revision 2:2.6.32~3+toi --append-to-version -3-amd64+toi --arch_in_name --initrd -j 2 kernel_image</code> And the resulting debian package will be named <code>linux-image-2.6.32-3-amd64+toi_2.6.32~3+toi_amd64.deb</code> Note that should actually be ''linux-image-2.6.32-3-amd64+toi_2:2.6.32~3+toi_amd64.deb'' but the epoch is excluded from the filename, the package version **will** include it \\ Note the epoch (''2:'') is used to prevent upgrades from debian's kernels at all costs (it won't be reflected in the filename.\\ While the kernel //name// will be: <code>$ uname -r
2.6.32-3-amd64+toi</code>
    * Build headers if wanted: <code>$ make-kpkg --rootcmd fakeroot --revision $KVER~$X+toi --append-to-version -$X-$ARCH+toi --arch_in_name --initrd -j $NCPUS kernel_headers</code>
  * Install ((If on install it errors about missing ''/boot/bzLinux-$KVER'', try adding ''kimage=vmlinuz'' to ''~/.kernel-pkg.conf'', and rebuild. Might be a temporary bug?)) <code># dpkg -i linux-image-$KVER-$X-$ARCH+toi_$KVER~$X+toi_$ARCH.deb</code>
    * Package ''linux-image-*'' will contain a couple links to the build location, if the corresponding ''linux-headers-*'' isn't installed these links will be removed. You can recreate the links by installing ''linux-headers-$KVER-$REV'' and re-installing ''linux-image-$KVER-$REV''.
  * Create an initrd if it doesn't exist ((Replace ''$REV'' with the value passed to ''make-kpkg'' in ''--append-to-version'')): <code># update-initramfs -k $VER-$REV -c</code>
    * If you had to create the initrd image, run ''update-grub'' too or the grub entry might lack the reference to initrd: <code># update-grub</code>

===== From pristine (upstream) source =====

FIXME This is to be expanded, for the time being refer to the above instructions to fill the gaps

Source: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-kernel-org-package

With modern kernels it's very simple. Here the version will include the pathlevel (2.6.x.y instead of 2.6.x), and AFAIK you can change the package revision but not install different builds of the same 2.6.x.y version in parallel.

I'm not yet too used to this method so I might be missing something.
FIXME I don't yet know if there's a standard way to create a headers deb.

  $ wget http://kernel.org/pub/linux/kernel/v2.6/linux-$KVER.tar.bz2
  $ tar jxvf linux-$KVER.tar.bz2 && cd linux-$KVER
  (patches)
  (make config)
  $ fakeroot make KDEB_PKGVERSION=$KVER+$REV deb-pkg
  (KDEB_PKGVERSION *must* start with a number)

Example:\\
With KVER=2.6.32.41 and REV=toi-1 this will produce packages ''linux-image-2.6.32.41_2.6.32.41+toi-1_amd64.deb'' and ''linux-firmware-image_2.6.32.41+toi-1_all.deb''.\\
Where kernel package name is ''linux-image-2.6.32.41'' and version ''2.6.32.41+toi-1''.

Kernel version (''$ uname -r'') will be 2.6.32.41, modules will go into ''/lib/modules/2.6.32.41''.

==== Headers ====

FIXME This notes have not much //hand-holding//, don't mess with this unless you know what you're doing.

Debian's ''linux-headers'' packages (used to build out-of-tree modules) won't be created from a pristine kernel.

To have a viable //homebrewed// tree to build modules, clean the tree and remove unneeded files:

(Replace $YOURARCH with your architecture, x86_64 users should use x86)

   $ cd /usr/src/.../linux-source-$KVER
   $ make clean prepare # prepare is required for building out-of-tree modules
   $ mkdir /usr/src/linux-headers-$KVER+$REV
   $ tar -c --exclude '*.c' --exclude '*.o' --exclude '*.ko' arch/$YOURARCH include scripts Makefile .config Module.symvers | ( cd /usr/src/linux-headers-$KVER+$REV ; tar xv )

Note this self-baked tree contains much more cruft than a proper linux-headers package, but I'm unsure on what to remove.

You'll have to fix the /lib/modules/$KVER/build link unless you build the package in the correct path (/usr/src/linux-headers-$KVER+$REV).

====== Fix for Huge package/modules ======

Beware, if copying the official distribution's config, debugging symbols might be enabled (raising the kernel package to a few hundred megs!).

Quick way to re-configure it:
  $ sed -i '/CONFIG_DEBUG_KERNEL/d' .config