While chasing edits on the Arch Wiki a couple of weeks ago, I stumbled upon this page: Kernels/Compilation/Traditional; fortuitously, it transpired. For it piqued my interest sufficiently for me to try my hand at compiling my own kernel, and—after half a dozen attempts at getting it right—I had no sooner switched to my custom built kernel as the default in my boot manager when 3.10.2 landed in [testing] and would not boot. At all.

I still have no idea why 3.10.2 would do nothing other than fail silently, but the convenience of having another kernel to switch to without needing a rescue image or any other panicked interventions immediately won me over. In the years that I have used Arch, this was my first near brush with an unbootable system¹ and the small amount of effort required to mitigate this risk with a custom or alternate kernel seems a smart investment to me at this point.²

The documentation on the wiki is both comprehensive and easy to follow. The lessons I learned between kernels zero and three or four were mostly around ensuring the correct modules were configured into the build. One surefire way to make this a tedious and laborious process, should you be so inclined, is to blindly enable and disable settings in menuconfig.

Around about the time of the fourth failed build (well, the builds were working but the kernel wasn’t booting or was booting with missing functionality), I decided to switch approaches and go down the localmodconfig route. This, for someone with my limited experience with this aspect of GNU/Linux, was in retrospect a decision I should have made sooner.

First, I started with streamline_config.pl, a helpful script that allows you to create a .config file containing only those modules necessary to your currently running kernel³. This yielded a booting kernel at the first attempt. It turns out, though, that you still need to ensure that all of the modules you are going to need, at any time in the future, are loaded. I missed a couple.

Then I discovered this script by graysky, modprobed_db. For a newbie to kernel compilation, this is simply invaluable. It allows you to create a record of your used modules over time, compare it with those that are currently loaded and then—right before you make localmodconfig—load the remaining necessary ones. Foolproof kernel compilation. Just like that. Brilliant. And, naturally enough, it is in the AUR.

Run the script, create your .conf file and database in $XDG_CONFIG_HOME/modprobed_db{,.conf} and then either call it from a cron job or, if you are impatient like me, spend a frenzied 10 minutes plugging ALL the devices you own into your machine, and you are good to go. Running sudo modprobed_db recall will load all of the required modules, you generate your kernel .config, check it to make sure it is complete and then run make.

On my laptop, I have 115 modules activated for a build, 10 of which need to be recalled prior to creating the .config. When I was trying to debug 3.10.2, I compiled the vanilla Arch kernel using ABS and it took almost exactly 60 minutes using all four threads on my i5. Building my own kernel is done and installed in under 10.

I susbcribed to the RSS feed for kernel versions and now, whenever a new stable kernel is posted, I wget it, compile it and boot from it. As new Arch versions appear in the repositories, they are updated by pacman and happily coexist on my /boot; thereby ensuring that the likelihood of me being unable to boot my machine (other than through PEBKAC) has hopefully been staved off for another five years.

The next step would be to write a script that completely automates the process…

Update 7/8/13

After poring over PKGBUILDS in the AUR, principally graysky’s linux-ck PKGBUILD, and the official ABS PKGBUILD, I decide to write my own to automate the above. It works well enough for me, but hasn’t been tested more widely. You will need to ensure that you have an up-to-date modprobed_db database with all of your required modules listed and that you have configured sudoers to have this run from the PKGBUILD.

The PKGBUILD and the attendant files are in my bitbucket repo: let me know if there are any issues with this approach.

See also the follow up post on automating this process: Automating Kernel Builds

Notes

1. Other than those occassions for which I bear complete responsibility…
2. There are, of course, other benefits such as the self-satisfied glow of geek accomplishment.
3. This is located in scripts/kconfig/.

Creative Commons image of kernels on Flickr by Nadia Prigoda-Lee.