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.

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:

arm_freq=1000
sdram_freq=500
core_freq=500
over_voltage=2

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.