Just for the fun and/or challenge of it the other day, I decided to try to compile my own kernel. Having cut my computing teeth on the [1] Computer Underground Digest (CuD) archives, I learned that there was a certain thrill to compiling one’s own Linux kernel. (Indeed, if it were not for e-zines like [2] Phrack and its ilk, I would never have gotten into C++ programming, and I would never have found out about this glorious operating system called Linux, which was touted to me in my malleable youth as a programmer’s paradise.) This used to be a much bigger deal than it is now; when I was running Debian 2.0 back in 1998 (ahh, beloved `hamm’) and talking to people on EFNet’s #linux channel about it, they made it seem like it was a matter of such gravity that only the hardest-core nerds could do it right.

That’s no longer strictly true, though it helps to be a geek to fully appreciate the fun of it. You might have to be a mechanic to fully appreciate rebuilding an engine; and a mason to appreciate brickwork well-done; and a composer to fully enjoy composing. So it is with Linux, but only perhaps: I’m not really so much a programmer any more, but I really enjoyed this. It’s not difficult, and the rewards are great.

Bars in the past to my compiling weren’t just feeling intimidated; for a long while, I was running a 466MHz Celeron on an Asus P2B-F (both of which, by the way, I’m looking to sell; let me know if you want to buy and I’ll post it on eBay or we can discuss pricing if I haven’t yet posted it) with RHL 7.3, then 9.0, and didn’t really bother with messing with the kernel because it did what it needed to do. It wasn’t my primary box, it was just my router/firewall/webserver for a while, because the idea of running a webserver from my apartment tickled me. The machine that replaced that was an Athlon 1700+ running on a Shuttle mobo whose ID I can’t remember at the moment. That was a good system, except I had a bad stick of RAM in it that crippled the entire system from running Linux (because, as we all know, Linux uses your hardware’s capabilities much more effectively than Windows). (I didn’t confirm that it was really corrupt until a few weeks ago, because I had RMA‘d the first stick. What are the odds?) So I couldn’t really run Linux except on the router/webserver (which was in my closet) for about two years.

Well, now I have all-working hardware. A brand-new base system using AMD’s Athlon64 3200+ and an Abit KV8 Pro. I look forward to overclocking that beast when I can afford a more effective cooling system, but that’s a project best saved for exam time, since of course the extent of procrastination must match the immediacy of the need to perform! All right. Suffice it to say that this hardware is fully capable of compiling things from scratch; and my hard drive has enough for every development package that came with Fedora Core 2 and then some.

I started by going to [3] www.kernel.org and downloading the latest kernel source (2.6.8.1 as of this writing), as well as the patches. Then I found, through Googling of course, a Kernel-HOWTO that is updated beyond the original version, which is no longer quite as relevant as it used to be, though it will remain an esteemed part of the canon of Linux documentation. The original author, according to [4] TLDP, does indeed [5] plan to release another version of the HOWTO. Meanwhile, Kwan Lowe has written another document, the “[6] Kernel Rebuild Guide.” It was this document that guided me through this process, and I recommend it if you’re building (or considering building) a 2.6.x kernel.

$ cd linux-2.6.8.1
$ patch -p1 <../patch-2.6.9-rc2
$ patch -p1 <../patch-2.6.9-rc2-bk8

(Copious output from each instance of the patch program have been omitted.) It should be noted that this was ERRONEOUS. I needed to apply a reverse-patch to the kernel first, according to user amosf at [7] LinuxQuestions.org, and this worked. (I will give the full sequence shortly.)

At this point, I ran make mrproper and then make xconfig in a terminal, whereupon a GUI interface for kernel configuration popped up. I have to say I’m impressed by that. It’s no revolution, but it’s certainly better than the TUI of yore. I configured everything as I thought it needed to be, then continued:

$ make bzImage && make modules
$ su
# make modules_install
# /sbin/mkinitrd initrd-2.6.8.1.img 2.6.8.1
No module sata_via found for kernel 2.6.8.1, aborting.

This was disappointing. What I had done wrong were two things: first of all, I didn’t rename the kernel version-directory. I was not compiling the 2.6.8.1 kernel, I was compiling the 2.6.9-rc2-bk8 kernel; and secondly, I was under the mistaken impression that, if I could afford the diskspace, I should compile in EVERYTHING that I could. That was wrong: subsequent research says that all ALSA drivers and all SATA drivers, at this point, need to be modular.

Hence, this past time, on Sunday the 26th, I used the following methods to get a custom kernel (my comments are preceded by “—”):

$ tar jxf linux-2.6.8.1.tar.bz2
$ cd linux-2.6.8.1
— unpack this kernel and switch to the directory it creates
$ patch -Rp1 <../patch-2.6.8.1
$ patch -p1 <../patch-2.6.9-rc2
$ patch -p1 <../patch-2.6.9-rc2-bk12
— notice update of “bk” version; also note patches were in parent dir of linux-*
$ cd .. ; mv linux-2.6.8.1 linux-2.6.9-rc2-bk12
— rename this directory to reflect version patches
$ tar jcf linux-2.6.9-rc2-bk12.tar.bz2 linux-2.6.9-rc2-bk12/
— optional: create a compressed tar archive so I don’t have to re-patch if I need to rebuild again
# mv /home/mike/download/linux-2.6.9-rc2-bk12 /usr/src
— notice I’m now root
# cd /usr/src/linux-2.6.9-rc2-bk12/
# make mrproper && make xconfig
— configured the kernel to use modules for sound and serial ATA interfaces
# make bzImage && make modules && make modules_install
# /sbin/mkinitrd initrd-2.6.9-rc2-bk12.img 2.6.9-rc2-bk12
— it is now ready; copy everything over to /boot
# cp arch/i386/boot/bzImage /boot/bzImage-2.6.9-rc2-bk12
# cp System.map /boot/System.map-2.6.9-rc2-bk12
# ln -s /boot/System.map-2.6.9-rc2-bk12 /boot/System.map

Then I had to add the information to grub.conf, which on my FC2 system is symbolically linked to /etc/grub.conf:

title Linux 2.6.9-rc2-bk12
root (hd0,0)
kernel /bzImage-2.6.9-rc2-bk12 ro root=LABEL=/ hda=238216,16,63
initrd /initrd-2.6.9-rc2-bk12.img

Note that the extra component there on the “kernel” line is specification for my hard drive parameters, since for some reason my BIOS is ridiculous and won’t pick it up and I haven’t flashed it yet. (Could have to do with the IDE cables too, though.)

I rebooted the system, and not only is the sound better than ever, I got no errors, and this is the fastest kernel I’ve ever run. Success!

Just for the fun and/or challenge of it the other day, I decided to try to compile my own kernel. Having cut my computing teeth on the [8] Computer Underground Digest (CuD) archives, I learned that there was a certain thrill to compiling one’s own Linux kernel. (Indeed, if it were not for e-zines like [9] Phrack and its ilk, I would never have gotten into C++ programming, and I would never have found out about this glorious operating system called Linux, which was touted to me in my malleable youth as a programmer’s paradise.) This used to be a much bigger deal than it is now; when I was running Debian 2.0 back in 1998 (ahh, beloved `hamm’) and talking to people on EFNet’s #linux channel about it, they made it seem like it was a matter of such gravity that only the hardest-core nerds could do it right.

That’s no longer strictly true, though it helps to be a geek to fully appreciate the fun of it. You might have to be a mechanic to fully appreciate rebuilding an engine; and a mason to appreciate brickwork well-done; and a composer to fully enjoy composing. So it is with Linux, but only perhaps: I’m not really so much a programmer any more, but I really enjoyed this. It’s not difficult, and the rewards are great.

Bars in the past to my compiling weren’t just feeling intimidated; for a long while, I was running a 466MHz Celeron on an Asus P2B-F (both of which, by the way, I’m looking to sell; let me know if you want to buy and I’ll post it on eBay or we can discuss pricing if I haven’t yet posted it) with RHL 7.3, then 9.0, and didn’t really bother with messing with the kernel because it did what it needed to do. It wasn’t my primary box, it was just my router/firewall/webserver for a while, because the idea of running a webserver from my apartment tickled me. The machine that replaced that was an Athlon 1700+ running on a Shuttle mobo whose ID I can’t remember at the moment. That was a good system, except I had a bad stick of RAM in it that crippled the entire system from running Linux (because, as we all know, Linux uses your hardware’s capabilities much more effectively than Windows). (I didn’t confirm that it was really corrupt until a few weeks ago, because I had RMA‘d the first stick. What are the odds?) So I couldn’t really run Linux except on the router/webserver (which was in my closet) for about two years.

Well, now I have all-working hardware. A brand-new base system using AMD’s Athlon64 3200+ and an Abit KV8 Pro. I look forward to overclocking that beast when I can afford a more effective cooling system, but that’s a project best saved for exam time, since of course the extent of procrastination must match the immediacy of the need to perform! All right. Suffice it to say that this hardware is fully capable of compiling things from scratch; and my hard drive has enough for every development package that came with Fedora Core 2 and then some.

I started by going to [10] www.kernel.org and downloading the latest kernel source (2.6.8.1 as of this writing), as well as the patches. Then I found, through Googling of course, a Kernel-HOWTO that is updated beyond the original version, which is no longer quite as relevant as it used to be, though it will remain an esteemed part of the canon of Linux documentation. The original author, according to [11] TLDP, does indeed [12] plan to release another version of the HOWTO. Meanwhile, Kwan Lowe has written another document, the “[13] Kernel Rebuild Guide.” It was this document that guided me through this process, and I recommend it if you’re building (or considering building) a 2.6.x kernel.

$ cd linux-2.6.8.1
$ patch -p1 <../patch-2.6.9-rc2
$ patch -p1 <../patch-2.6.9-rc2-bk8

(Copious output from each instance of the patch program have been omitted.) It should be noted that this was ERRONEOUS. I needed to apply a reverse-patch to the kernel first, according to user amosf at [14] LinuxQuestions.org, and this worked. (I will give the full sequence shortly.)

At this point, I ran make mrproper and then make xconfig in a terminal, whereupon a GUI interface for kernel configuration popped up. I have to say I’m impressed by that. It’s no revolution, but it’s certainly better than the TUI of yore. I configured everything as I thought it needed to be, then continued:

$ make bzImage && make modules
$ su
# make modules_install
# /sbin/mkinitrd initrd-2.6.8.1.img 2.6.8.1
No module sata_via found for kernel 2.6.8.1, aborting.

This was disappointing. What I had done wrong were two things: first of all, I didn’t rename the kernel version-directory. I was not compiling the 2.6.8.1 kernel, I was compiling the 2.6.9-rc2-bk8 kernel; and secondly, I was under the mistaken impression that, if I could afford the diskspace, I should compile in EVERYTHING that I could. That was wrong: subsequent research says that all ALSA drivers and all SATA drivers, at this point, need to be modular.

Hence, this past time, on Sunday the 26th, I used the following methods to get a custom kernel (my comments are preceded by “—”):

$ tar jxf linux-2.6.8.1.tar.bz2
$ cd linux-2.6.8.1
— unpack this kernel and switch to the directory it creates
$ patch -Rp1 <../patch-2.6.8.1
$ patch -p1 <../patch-2.6.9-rc2
$ patch -p1 <../patch-2.6.9-rc2-bk12
— notice update of “bk” version; also note patches were in parent dir of linux-*
$ cd .. ; mv linux-2.6.8.1 linux-2.6.9-rc2-bk12
— rename this directory to reflect version patches
$ tar jcf linux-2.6.9-rc2-bk12.tar.bz2 linux-2.6.9-rc2-bk12/
— optional: create a compressed tar archive so I don’t have to re-patch if I need to rebuild again
# mv /home/mike/download/linux-2.6.9-rc2-bk12 /usr/src
— notice I’m now root
# cd /usr/src/linux-2.6.9-rc2-bk12/
# make mrproper && make xconfig
— configured the kernel to use modules for sound and serial ATA interfaces
# make bzImage && make modules && make modules_install
# /sbin/mkinitrd initrd-2.6.9-rc2-bk12.img 2.6.9-rc2-bk12
— it is now ready; copy everything over to /boot
# cp arch/i386/boot/bzImage /boot/bzImage-2.6.9-rc2-bk12
# cp System.map /boot/System.map-2.6.9-rc2-bk12
# ln -s /boot/System.map-2.6.9-rc2-bk12 /boot/System.map

Then I had to add the information to grub.conf, which on my FC2 system is symbolically linked to /etc/grub.conf:

title Linux 2.6.9-rc2-bk12
root (hd0,0)
kernel /bzImage-2.6.9-rc2-bk12 ro root=LABEL=/ hda=238216,16,63
initrd /initrd-2.6.9-rc2-bk12.img

Note that the extra component there on the “kernel” line is specification for my hard drive parameters, since for some reason my BIOS is ridiculous and won’t pick it up and I haven’t flashed it yet. (Could have to do with the IDE cables too, though.)

I rebooted the system, and not only is the sound better than ever, I got no errors, and this is the fastest kernel I’ve ever run. Success!