{"id":454,"date":"2009-07-04T01:39:17","date_gmt":"2009-07-04T00:39:17","guid":{"rendered":"http:\/\/wp.devco.net\/?p=454"},"modified":"2009-11-04T15:33:21","modified_gmt":"2009-11-04T14:33:21","slug":"compiling_custom_kernels_in_debian","status":"publish","type":"post","link":"https:\/\/www.devco.net\/archives\/2009\/07\/04\/compiling_custom_kernels_in_debian.php","title":{"rendered":"Compiling Custom Kernels in Debian"},"content":{"rendered":"
[ <\/span><\/span>Click here if you want to skip to the instructions… ]<\/span><\/span><\/em><\/a> <\/em><\/div>\n

<\/p>\n

<historylesson><\/div>\n

Things aren’t how they used to be.
\n
\nIt 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.
\n
\nThis 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.
\n
\nThings 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.
\n
\nWell, usually. Sometimes, you really need to tweak some code<\/a> to get the feature or performance you were counting on, or try out some awesome new patch<\/a> which might just revolutionise the systems you are developing.<\/p>\n

<\/historylesson><\/div>\n

\nI’m a sucker for Debian. I love dpkg and apt(-itude). The package manager is powerful and I enjoy using it.\u00a0I like everything except building packages from source<\/strong><\/em>. 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.
\n
\nBuilding kernel packages is worse yet.<\/strong> 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.
\n
\nI’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.
\n
\n
\nSo 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:
\n
\n1) Make sure the build dependencies are installed<\/p>\n

apt-get build-dep linux-image-2.6.30-1-686<\/pre>\n
\n2) Obtain the source. Note that apt downloads the original, virgin kernel\u00a0source tarball, and then applies a load of Debian-specific patches.<\/p>\n
cd \/usr\/src\r\napt-get source linux-image-2.6.30-1-686\r\ncd linux-2.6-2.6.30<\/pre>\n
\n3) Apply your patches, tweak the source, etc.<\/p>\n
patch -p1 < ..\/path\/to.patch<\/pre>\n
\n4) Customise the package version, substituting ‘custom’ with whatever you want. You will be presented with a changelog entry to edit.<\/p>\n
debchange --no-auto-nmu -l 'custom'<\/pre>\n
\n5) Prepare for the Debian build (substituting your target architecture)<\/p>\n
fakeroot debian\/rules debian\/build debian\/stamps\r\nfakeroot make -f debian\/rules.gen setup_i386_none_686<\/pre>\n
\n6a) If you want a custom kernel configuration, now’s the time to do it, using\u00a0make menuconfig<\/em> or\u00a0make oldconfig<\/em> or whatever. You can use Debian’s .config file as your starting point.\u00a0NOTE:<\/strong> once you’ve created your new .config, you need to copy it somewhere safe,\u00a0delete<\/em><\/strong> the whole source directory, and\u00a0go back to step<\/strong> 2<\/strong>, else the Debian build process will complain.\u00a0I don’t know a way around this.<\/p>\n
cp debian\/build\/config.i386_none_686 .config\r\nmake menuconfig<\/pre>\n
\n6b) After going back through steps 2-5, you need to copy your custom .config into the Debian build tree<\/p>\n
cp \/path\/to\/.custom debian\/build\/config.i386_none_686<\/pre>\n
\n7) Compile and build the kernel image .deb<\/p>\n
fakeroot make -j3 -f debian\/rules.gen binary-arch_i386_none_686<\/pre>\n
\n8 ) Build the linux, common, and linux-libc-dev (for \/usr\/include\/linux) headers packages:<\/p>\n
fakeroot make -f debian\/rules.gen binary-arch_i386_none_real binary-arch_i386_real<\/pre>\n
\nYou now have a nice shiny set of .deb files in\u00a0\/usr\/src<\/em>
\n
\nFinally, you will want to\u00a0pin or prioritise<\/a> your custom kernel package above any upstream updates so that you don’t inadvertantly lose yours after an apt-get upgrade.
\n
\nI’m sure there are easier ways to do this, but I’ve yet to discover them!<\/p>\n","protected":false},"excerpt":{"rendered":"
[ Click here if you want to skip to the instructions… ] <historylesson> 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 […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","footnotes":""},"categories":[5],"tags":[18,20,17,19],"_links":{"self":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/454"}],"collection":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/comments?post=454"}],"version-history":[{"count":12,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/454\/revisions"}],"predecessor-version":[{"id":1109,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/posts\/454\/revisions\/1109"}],"wp:attachment":[{"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/media?parent=454"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/categories?post=454"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devco.net\/wp-json\/wp\/v2\/tags?post=454"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}