How to build your own kernel on Slackware Linux

With all the noise lately about Dirty COW (CVE-2016-5195) and the lack of patched kernels from Slackware’s “Benevolent Dictator for Life”, I decided it was time to roll up the sleeves and get it done. Since Slackware doesn’t have a “sophisticated” build system and all that grease, it’s a trivial matter to step up to the plate and take responsibility for your own system. I’ll be using “vanilla-kernelversion” as my tag for the kernel and initrd. Also notice that I build my kernels as a normal user.

Download and verify the kernel source

Create a directory for building the new kernel:

mkdir ~/kernel; cd ~/kernel

Download the kernel source and signature from


Decompress the archive:

unxz linux-4.4.27.tar.xz

Verify the .tar archive against the signature (this will fail as I don’t have the public key yet):

gpg2 --verify linux-4.4.27.tar.sign

Notice the “key ID” from the output of the previous step and download it from a key server:

gpg2 --keyserver hkp:// --recv-keys 6092693E

Verify the .tar archive against the signature again and look for the “Good signature” message:

gpg2 --verify linux-4.4.27.tar.sign

Extract the tarball if everything checked out:

tar -xvf linux-4.4.27.tar

Enter the kernel source directory and clean the kernel tree:

cd linux-4.4.27
make clean && make mrproper

Configuring and compiling the kernel

There is obviously no reason to configure a brand new kernel from scratch when already running a generic stock Slackware kernel. Make sure you’re still in the kernel source directory and issue the following command to copy the running kernel configuration:

zcat /proc/config.gz > .config

For simplicity, I want all new configuration options to be set to their defaults. By using “olddefconfig” you’ll automatically chose the defaults without any manual handling:

make olddefconfig

To speed up the compiling, make sure to run make with the “-j” option (number of cores+1):

make -j9

Compiling kernel modules and installation

Everything from this point and onward is done as root. Switch to the root user and reenter the kernel source directory.
Proceed to install the kernel modules:

make modules_install

Copy the kernel to the boot directory and rename it (the location of the kernel image is the same for x86_64 and x86):

cp arch/x86/boot/bzImage /boot/vmlinuz-vanilla-4.4.27

Copy the to the boot directory and rename it:

cp /boot/

Copy the kernel .config to the boot directory and rename it:

cp .config /boot/config-vanilla-4.4.27

Enter the boot directory:

cd /boot

Delete the old link:


Create a new link:

ln -s

Initrd and LILO

I need to create an initial ramdisk to boot my kernel so I’ll use the mkinitrd command to create one. I’ll leave it to Slackware to identify which modules are needed by running with the “-k” parameter to specify the new kernel version. To avoid wiping my existing initrd I’ll name it initrd-vanilla-4.4.27. I’ll use the output from the generator to create the initrd (remember to modify the initrd name):

/usr/share/mkinitrd/ -k 4.4.27
# Don't go copying the next line, that's an example.  
mkinitrd -c -k 4.4.27 -f ext4 -r /dev/sda2 -m jbd2:mbcache:ext4 -u -o /boot/initrd-vanilla-4.4.27.gz

To boot the new kernel, it needs to be added to LILO. Make sure to not remove the entry specifying your running Slackware kernel. If the new kernel doesn’t run, it’s practical to boot into a working one.

nano /etc/lilo.conf

Create a new entry for the new kernel (I’m using mine as default but that’s optional):

default = Vanilla  

image = /boot/vmlinuz-vanilla-4.4.27
  root = /dev/sda2
  initrd = /boot/initrd-vanilla-4.4.27.gz
  label = Vanilla

Finally, run the lilo command and it’s all done.


But I’m using ELILO

Me too, replace the LILO section with this part: Configuring ELILO with a generic kernel on Slackware 14.2

I’m sick of WordPress so I wrote a new theme to make it worse

In an attempt to have a WordPress theme optimized for running on the Raspberry Pi 3, I went through the hurdles of writing my own theme. Among my goals was to create something entirely free of third party CSS and JavaScript frameworks. Actually, I wanted a theme free from JavaScript altogether and in my opinion there are already more than enough websites built on the Bootstrap framework (you’ll recognize them, they all look the same).

Another important aspect of making my own theme was to fight the continuous introduction of new features in WordPress that in my opinion are either useless or expose a new attack surface. Gone are the days when WordPress was a simple piece of blogging software, today it has become an application framework (or is it platform) and I won’t have anything to do with it if I can help it.

If you are curious as to what features I’m unhappy with, please take a look at the “disabled functionality” section on the pureRegression theme page.

Instead of adding more bloat to WordPress, I would really like to see the developers focusing on making the “writing” experience better. WordPress is thirteen years old and I’m still using an external text editor to write my posts. If you compare working with content in WordPress to the Ghost blogging platform, I would argue that the latter is superior in every way. Sadly I can’t remember a single WordPress core update in the last six years that actually introduced any improvement when it comes to working with content.

GTmetrix score
GTmetrix performance score.

Though my home-brewed WordPress theme doesn’t adhere closely to the official WordPress guidelines and must unfortunately suffer from my lack of CSS skills, it does at least shine when it comes to load times and performance. That is good enough for me while I keep looking for another long term solution for this blog. My only requirement is that the software can run on a Raspberry Pi 3 powered by Slackware ARM, and has support for importing posts from WordPress.

I’ll probably end up going with a static generator, currently Hugo is looking very interesting.

Downtime and kernel upgrade to patch “Dirty COW”

I’ve just performed a kernel upgrade on my Raspberry Pi 3 to patch CVE-2016-5195 aka “Dirty COW”. Privilege escalation vulnerabilities in the Linux kernel always gets my heart rate going, so I decided to immediately get the latest kernel (4.4.26) and firmware for this server.

The tool I’m using for kernel and firmware updates is rpi-update by Hexxeh. Usually I would first deploy updates to my RPi based build boxes for testing, but desperate times call for desperate measures. Anyhow, I’ve not noticed any regressions or other issues so far, but with bleeding edge there’s always a risk.

Rpi-update is intended for use with Raspbian but I’ve been using it on Slackware ARM for 18 months without issues. Still, before going down this path make sure it’ll work with your distribution. For all you IoT owners out there, it’s time to take some responsibility and start patching.

rpi-update on Slackware ARM
Rpi-update on Slackware ARM installing the latest kernel and firmware.