systemd on Slackware! Something, Something, Something, Dlackware

Dlackware is not your average “GNOME for Slackware” project but instead aims to take the slack out of Slackware. What you get in return is the latest in “enterprise” technology. Dlackware delivers a fully functional GNOME 3.22 desktop with PAM, Wayland and systemd.

While ignoring the immediate risk of being burned as a heretic, I could not withstand the urge to give this project a spin on my HP 250 Notebook.


After a good 10 hours of compiling, by way of the Dlackware build system, I could finally watch the systemd startup on my very own Slackware Linux system. What else is there to say, it just worked and nothing bad happened. It may have felt wrong but that’s about it. The systemd implementation seems sound and worked as expected from my previous experiences with systemd.

systemd on Slackware Linux 14.2
systemd on Slackware Linux 14.2


It’s been years since I’ve tried GNOME but I was pleasantly impressed with how the desktop environment has evolved. It looks and feels very professional and I believe I could get used to GNOME again (if I had to). I still find some of the GNOME applications too simplistic compared to their KDE counterparts, but that’s really a matter of preferences.

GNOME 3.22 on Slackware Linux 14.2
GNOME 3.22 on Slackware Linux 14.2

I didn’t experiment with the “online accounts” integration as I prefer to keep my personal data to myself. Thankfully GNOME respects your privacy and doesn’t keep nagging about connecting to the cloud. To summarize, running GNOME 3.22 on Slackware has been great, no crashes or other issues worth mentioning.


I’m very impressed with what the developers behind this project has delivered. In addition to the technical merits, they have also provided an unlimited GNOME 3 experience to the Slackware community.

However, any mention of systemd in Slackware circles tend to get ugly fast so I’m not entirely convinced that the project will enjoy a substantial userbase. Personally, I did enjoy the experience even if I do belong in the greybeard camp. I’ll definitely keep an eye on the project in the future.


An installation guide is available at github.
Announcement thread at

Don’t blame me

Dlackware rebuilds and replaces system components. Just indiscriminately running “slackpkg upgrade-all” after installation will break your system.

# /etc/slackpkg/blacklist
# This is a blacklist file.

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

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.