Things aren’t how they used to be.
It seems I spent most of the ’90s and the early ’00s (damn you Y2K!) building my own kernels. The preposterous thought of sticking with the default kernel of your chosen distribution simply never crossed a lot of minds. For one thing, your hardware was pretty much guaranteed not to work out of the box, and RAM was expensive! It was in your best interests to tweak the hell out of the settings to get the best performance out of your hardware, and to avoid compiling in any unnecessary code or modules, to reduce your system memory footprint.
This involved much learning of new terminology and options, many failures and unbootable systems, and many trips to the local steakhouse or coffee shop, since each compile would take hours on your trusty 80386 or 80486.
Things aren’t the way they used to be, thank goodness. Chances are, the vanilla kernel you received with your latest Masturbating Monkey Ubuntu 13.0 installation performs well and works with most of your hardware. You don’t need to roll your own kernel. In fact, you should probably avoid it, especially if you’re thinking of installing servers in a live production environment.
Well, usually. Sometimes, you really need to tweak some code to get the feature or performance you were counting on, or try out some awesome new patch which might just revolutionise the systems you are developing.
I’m a sucker for Debian. I love dpkg and apt(-itude). The package manager is powerful and I enjoy using it. I like everything except building packages from source. It’s rarely as straightforward as it should be, and sometimes it’s incredibly difficult to obtain a package which installs the same way and into the same places with the same features as the upstream pre-built package that you’re supposedly building.
Building kernel packages is worse yet. Far worse. When rolling your own kernel, especially if you don’t want the package manager to install the latest version over your own, you are forced to play ball with apt, and you must play by apt’s rules.
I’ve tried a multitude of incantations of dpkg-buildpackage, debuild, make-kpkg, etc. All I want to be able to do is patch the kernel source, make some changes, append a custom version tag, and build a .deb which I can safely install, yet each HOWTO or set of instructions I tried failed to do this to my (misguided?) specifications. I had particularly nasty problems with the grub update post-inst scripts in all cases.
So here’s a script-like set of commands and comments explaining how I now do this, using kernel 2.6.30 on a 32-bit x86 target platform as an example:
1) Make sure the build dependencies are installed
apt-get build-dep linux-image-2.6.30-1-686 |
2) Obtain the source. Note that apt downloads the original, virgin kernel source tarball, and then applies a load of Debian-specific patches.
cd /usr/src apt-get source linux-image-2.6.30-1-686 cd linux-2.6-2.6.30 |
3) Apply your patches, tweak the source, etc.
patch -p1 < ../path/to.patch |
4) Customise the package version, substituting ‘custom’ with whatever you want. You will be presented with a changelog entry to edit.
debchange --no-auto-nmu -l 'custom' |
5) Prepare for the Debian build (substituting your target architecture)
fakeroot debian/rules debian/build debian/stamps fakeroot make -f debian/rules.gen setup_i386_none_686 |
6a) If you want a custom kernel configuration, now’s the time to do it, using make menuconfig or make oldconfig or whatever. You can use Debian’s .config file as your starting point. NOTE: once you’ve created your new .config, you need to copy it somewhere safe, delete the whole source directory, and go back to step 2, else the Debian build process will complain. I don’t know a way around this.
cp debian/build/config.i386_none_686 .config make menuconfig |
6b) After going back through steps 2-5, you need to copy your custom .config into the Debian build tree
cp /path/to/.custom debian/build/config.i386_none_686 |
7) Compile and build the kernel image .deb
fakeroot make -j3 -f debian/rules.gen binary-arch_i386_none_686 |
8 ) Build the linux, common, and linux-libc-dev (for /usr/include/linux) headers packages:
fakeroot make -f debian/rules.gen binary-arch_i386_none_real binary-arch_i386_real |
You now have a nice shiny set of .deb files in /usr/src
Finally, you will want to pin or prioritise your custom kernel package above any upstream updates so that you don’t inadvertantly lose yours after an apt-get upgrade.
I’m sure there are easier ways to do this, but I’ve yet to discover them!
