I used a Cubieboard as a personal server until October, running Kanboard, tt-rss and some other Web apps there. It allowed me to keep more of my data at home and practice some more system administration.
Why Cubieboard
Initially I wanted a computer that would work during the night in my bedroom. This required a fanless design and therefore a low power usage. (Now I have a separate room for the computers, so they don’t need to be so quiet, while I pay their power bills.)
I could have either used my BeagleBone Black, a Cubieboard or buy a different board. I haven’t chosen the BBB for this since its 512 MiB RAM is not enough for a Web app that maintain in my spare time (Cubieboard’s 1 GiB is enough), and I wanted a more stable storage than microSD: Cubieboard has a SATA port which I connected to an SSD (also no moving parts). Meanwhile, I can use the BBB for flashing and debugging coreboot which requires some downtime.
(Now I think I wouldn’t need the personal server to work at night, but it’s easier: I can read some Web comics when I resume my laptop from suspend and get daily mails from cron and Kanboard. Also I won’t forget to turn it on before accessing these while traveling.)
How it was configured
ARM makes booting slightly more
interesting
than on x86. It booted u-boot from a microSD card which loaded a
kernel from /boot on the same microSD card (I wasn’t able to make it
load a kernel from the SSD, while it was documented to support SATA)
which mounted a btrfs root filesystem from the SSD.
The server was running Debian Jessie, manually installed using its usual installer (with good support for such boards). I configured nearly all services running on top of it using Ansible. Much configuration was shared with my other computers, e.g. using OpenVPN, Postfix for relaying locally-generated mails to my VPS, etc.
Like all my computers (or, in case of Thinkpads, disks moved between computers), it had a unique hostname. I named it after Sam, the trusted friend of Alice, Bob and Frodo.
How I broke it
After receiving a mail from apticron about Debian package updates
being available, I ran aptitude full-upgrade. There was a kernel
upgrade, so I rebooted it. This worked many times, but it didn’t once
in October.
After getting the serial TTL cable (which required removing the top of its case), I found errors from initramfs. Root couldn’t have been mounted due to filesystem errors. Checking in another computer (a big advantage of SATA over soldered storage chips), I have seen many btrfs errors, while all interesting files could be read.
So I copied the filesystem image to my desktop, ran mkfs.btrfs,
copied all files to the new filesystem, in many reboot loops I fixed
/etc/fstab and some initramfs configuration. Then it was not
booting, probably not being completely configured to use the new
filesystem.
Now
Not being able to fix it ‘now’, I migrated services to my desktop
computer (really easy with Ansible). I used data restored from the
filesystem image and a daily PostgreSQL image. (I couldn’t get the
possibly corrupted newer PostgreSQL data: it won’t load files written
on a different architecture, requiring using pgdump on armhf.)
Two months passed and I haven’t noticed a need for that server, so I still haven’t fixed it and use the desktop as a personal server. There is a difference in the power bill, while I don’t know how much of it can be attributed to the desktop running more often now.
Future
When I set up a new personal server, I will think about filesystem
errors before it stops booting. Maybe periodically running btrfs
scrub or choosing an older filesystem would help. Certainly, I
should backup before installing any OS update. I should also get a
recovery method for when the OS won’t boot (very easy on x86).