Moo IL (or another Linux stream-of-consciousness entry)

[buzzy]

At the end of the last entry, I basically issued myself a challenge without realizing it: build a Linux kernel for a computer that is actually important. In this case, I do it in a virtual machine because it's easier to clean up any screw-ups. I've done this quite a few times, so the main goals are to get my 64-bit PCLinuxOS machine to run with a newer kernel (3.15-rc2) and to run that kernel faster than the one it comes with. The dmesg output shows the last message taking place at an average of 18.25 seconds into the boot for the Linux 3.12.18 kernel. RAM usage after things calm down on startup is 291.4 MiB. I'm assuming things were handed off to X at that point, so it would be out of the kernel's hands. Anyway, the most fun (?) is that time you spend going through all the options. There has to be thousands of options of things you can adjust, remove, or add, and some of the descriptions seem like a sarcastic person wrote them. I ended up spending an hour and a half configuring the kernel. Next it was time to compile. The build proceeded smoothly and quickly. When I rebooted with it, it failed. Then I realized it probably was using the initrd image from the old kernel, so I made my own with mkinitrd -v /boot/initrd-<version>.img <version>. That's when it worked. The boot was really plain, as I guess I removed something necessary for Plymouth. I dug through the dmesg output from the stock kernel that worked and traced it to VESA framebuffer support missing from my kernels. (I thought I turned that on because it was the only thing that seemed like it would work on a virtual machine's graphics card.) Once that worked, I kept chipping away at settings and rebuilding the kernel. I found that while SATA runs faster overall, running the hard drive on a SATA controller adds about five seconds to boot time versus the same hard drive on an old PATA controller. (It's a virtual machine, so I could even make it a SCSI or SAS drive if I wanted to.) Considering I got boot time down to 13.67-14.26 seconds, five seconds would make a huge difference, but I stuck with the SATA controller. The RAM after things settle down is 237.8 MiB, though I tinkered with some boot scripts to reduce the number of errors appearing in my dmesg output.

This was my basic workflow, with some of these commands changed for builds after the initial one:

# Before building, I turn off the swap because even though I'm never in any
# danger of running out of RAM throughout the build, some memory is sent to
# swap for some reason. If this wasn't a virtual hard drive, I wouldn't care.
make mrproper
# Choice of "make defconfig" or copy an an old
# config and doing "make oldconfig". Then "make menuconfig"
# If you have weirdness running the next command, "make clean", then
# just run a plain "make".
make -j4
su
make modules_install
# The exact <version> string can be found by looking in the /lib/modules folder.
# Just in case you some weird error when generating your initrd
cp -v arch/x86/boot/bzImage /boot/vmlinuz-<version>
# Next line is to keep the wrong Plymouth theme from being put in the initrd
plymouth-set-default-theme <theme name>
# Next line is only if an initrd already exists
rm -f /boot/initrd-<version>
mkinitrd -v /boot/initrd-<version>.img <version>
# Next would be whatever is required to make it bootable, like editing
# /boot/grub/menu.lst or running a shell script

So the obvious benefits from all this work: faster startup (at least 21.9% faster) and less RAM usage (about 18.3% less). Most of the hardware support in the stock kernel consisted of modules, and I compiled everything in, but my custom kernel image is only 11.5 KiB larger while reducing the modules folder from 38.9 MiB to 12.5 KiB of just configuration files. (I would've skipped module support entirely if it didn't mean I'd lose my customized boot screen and initrd support.) A less obvious benefit comes from manually configuring the horizontal and vertical screen resolution in the Input Device Support area of the kernel configuration. Because a maximized VirtualBox window is kind of a weird size (1366x672), I can actually specify that weird size and have the mouse work better. Previously, the mouse would jump around the screen if I got too close to the edges of the window. That could just be a coincidence though. If you contact me not too long after this is posted, I could send you my .config file. I would've put it in this entry, but that file is huge. I may try this with a non-virtual machine in the future. After all, I still have the kernel source on a server on my local network.