Slackware ARM on the Raspberry Pi 2 – 38 days later

Excited by the prospect of hosting my blog on the new Raspberry Pi 2, I decided lately to wave goodbye to the local datacenter and unleash a Slackware Linux box into the wild (full story here).

Everything went (mostly) without a hitch until I wanted to get back in sync with the Slackware-current tree. After applying the available updates and issuing a reboot, the system seemed operational and nothing from the logs gave any indication of imminent failure.

Vmscan.c - Linux VM subsystem
Bob, we have a problem!

The next morning however, the system was unresponsive and syslog seemed to point to the kernel swap daemon, complemented with page allocation errors and a flood of stalls on CPUs/tasks from RCU.  To make matters worse, the system would completely lock up during troubleshooting.

Forcing fsck on all partitions revealed errors on both the FAT32 /boot partition (dirty bit) and the /(root) ext4 partition (multiply-claimed blocks in inode). I suspect these errors were caused by overclocking the RPi2 to its limit as it seem the system might not have had time to sync changes to disk before shutting down.
In hindsight, I remember that I experienced data corruption with one PHP file in the WordPress installation directory, but at the time I blamed it on a borked upgrade. I should probably have taken it as a sign of troubles to come.

RPi2 modified config:

Raspberry Pi 2 Model B
Powered by SARPi2

After implementing these changes, a week has gone by without any more issues. Easing up on the overclocking means PHP execution is back to a crawl, but that’s what caching is for I guess.

Anyhow, the dream of independent hosting with Slackware ARM on the Raspberry Pi 2 lives to see another day.

WordPress on Raspberry Pi 2 running Slackware ARM

Two weeks ago, I decided to move this blog from its old hosting and deploy it on a Raspberry Pi 2. The geek in me could no longer resist the urge to discover if a $35 worth computer could replace the need for commercial hosting. Besides, what a great opportunity to finally get my hands on Slackware’s official ARM port.

RPi2 setup:

Raspberry Pi 2 Model B
Raspberry Pi 2 Micro USB Power Cable 1.2A
MicroSDHC Ultra UHS-I 32GB

LAMP setup:

Slackware ARM current
Package series: a, ap, d, l, k, n (and a few from “x”).
Apache 2.4.12 (rebuilt)
MariaDB 5.5.40 (rebuilt)
PHP 5.4.40 with mod_proxy_fcgi and php-fpm (rebuilt)

Non stock packages:
Modsecurity 2.9.0
Fail2ban 0.9.1

Why use Slackware and not a hard float port?

A hardware floating-point unit you say, well I’d never heard of it.

ARMv7 includes a hardware floating-point unit (FPU), with improved speed compared to software-based floating-point.

In short, Slackware is not optimized for modern ARM implementations and it would be reasonable to assume that performance could be improved on a hard float port.

WordPress performance out of the box

It was not great truth to be told, page load times using the twenyfifteen theme clocked in at around 2.5 seconds on average (using 17 queries). I’ve always believed WordPress to be a “lightweight” application, but I guess that’s up for debate. Anyhow, I decided to try my hand at overclocking the RPi2 to see if I could improve performance to something more sustainable for production.

RPi2 final config:


I tried to push the arm_freq higher, but that caused the RPi2 to cough and crash under high load. Pushing the RPi2 to its limit sliced off another second of page load time, which was good, but obviously not comparable to commercial hosting. It was pretty much as expected, but it still felt like somewhat of a disappointment. However, since I rely heavily on caching with any WordPress installation, this RPi2 was not out of the game yet.

Optimizing the environment

By installing the “WP Super Cache” plugin from Automattic, and optimizing Apache for serving cached and compressed content, the RPi2 turned into a regular powerhouse.

Latest Performance Report for:
Latest Performance Report for:

Analyzing the performance over at gave me a page speed score of 96% and a YSlow grade of 92%. That’s a decent result on any platform and I’m rather impressed with the performance of the Raspberry Pi 2 in that regard.

The fact that the RPi2 is sitting on my desk while being assigned a dynamic IP, instead of cooling off at a high tech data center  with next to unlimited bandwidth makes it even more enjoyable.

I have one sour note though, compiling software is painfully slow, but that should not come as a huge surprise.


This site will keep rolling on Raspberry Pi 2 and Slackware ARM until something breaks beyond repair. As Slackware current is ripe for an avalanche of updates that might be sooner than later. If that should be the case, then I’ll update the changelog with the latest turn of events.

Slackware ARM current hosting
Slackware ARM current – Now hosting

How to upgrade PHP on Slackware Linux

I usually leave patching of stock Slackware packages to our BDFL, but I’ll make a few exceptions. As of Fri Apr 03 2015, the stock PHP version on Slackware Linux 14.1 is at version 5.4.36. Looking at the PHP changelog, it would seem that this is not “optimal” for a production server.

To upgrade PHP to version 5.4.39, I’ll use the stock Slackware build scripts. Slackware will build PHP with the IMAP extension, which requires the c-client library to be available. This is taken care of by having the php.SlackBuild script build Alpine (alpine.SlackBuild) and subsequently copying the needed files to /usr/local/lib64/c-client/, before resuming with the PHP build.

For the record, I always recommend building packages for Slackware by using a dedicated build box where possible.

# Build directory
mkdir /tmp/source/
cd /tmp/source/

# Download the Alpine and PHP source
wget -r -l0 -nH --cut-dirs=5
wget -r -l0 -R tar.xz -nH --cut-dirs=5

# Make the build scripts executable
chmod +x /tmp/source/alpine/alpine.SlackBuild
chmod +x /tmp/source/php/php.SlackBuild

# Download PHP 5.4.39 source and signature from
cd /tmp/source/php/

# Verify the signature (
gpg --keyserver --recv-key 5DA04B5D
gpg --verify php-5.4.39.tar.bz2.asc

# Delete the signature
rm php-5.4.39.tar.bz2.asc

# Change file extension to set correct version for the package
sed -i 's/tar.xz/tar.bz2/g' php.SlackBuild

# Build Alpine and PHP

# Install the new version
upgradepkg /tmp/php-5.4.39-x86_64-1.txz

# restart php-fpm (if used) and apache
/etc/rc.d/rc.php-fpm restart
apachectl restart
Slackware PHP Build
Slackware Linux 14.1 running PHP 5.4.39

If all went according to plan, then lets make sure everything works as expected before we deploy to production servers.