Not a moment after I had walked out the door to catch a train to Berlin for the KDE e.V. board sprint (May 2023), there was a local power failure which took down my in-house IT. That wouldn’t be so bad, except it did not come back up. Cue gnashing of teeth from the people who stayed at home (but, really, should have been able to hack into the router to fix it).

What Went Wrong

  • The Pine H6 which provides DNS and DHCP to the house, did not come up. I’ve seen it before – a power droop leaves the eMMC discombobulated, and no amount of cajoling will get it back unless you pick the eMMC off the board and futz with it in a different machine.
  • The modem relies on the Pine H6 and does not provide fallback of its own (which would have allowed easy configuration of static IP and DNS, anyway).
  • My workstation, which I thought was configured with static IP, was set to DHCP instead, so it didn’t get an address at all.

Fixing fallback DNS and my workstation IP was simple.

Fixing the H6 was slightly more involved.

Why Was eMMC Involved At All

Originally the H6 also ran QuasselCore and some other services. These write to disk and are persistent. I had had bad experiences with write endurance of micro-SD cards. As in, they’re lousy in write-intensive scenarios and wear out quickly.

I figured eMMC such as used in the PineBook would be a better candidate for writable storage.

Since originally setting this up, I have stopped using QuasselCore. So the write-intensive and potentially large data-storage needs are gone. But the eMMC configuration lives on in my H6, which is disastrous when a power droop leaves it discombobulated.

Fixing The eMMC

On boot in FreeBSD I kept getting controller timeouts and device-read timeouts on the eMMC block device. The filesystem would not mount, and I would eventually get dropped down to single-user mode. Unfortunately, in single-user mode, you need to use the serial console to talk to the board (if I expect people at home to hack the router, maybe I should expect them to deal with serial ports too).

I am, frankly, not sure what I did right. I picked the eMMC off the H6, stuck it to an adapter which I had just received with the VisionFive V2, and dd‘ed the whole device to /dev/null. Since it did not throw any read errors or timeouts, I put it back on the H6 and wished for good luck.

Note to self: on the Pine H6, the EXP connector has pin 6 = GND, 7 = TX (goes to RX on the USB-to-serial), 8 = RX. Those are the easiest to count-out pins. Also, they’re bent on my board from all the connecting-and-disconnecting I do.

Making The eMMC Unnecessary

Originally I added the eMMC for write-intensive large data sets, but those have gone away on this machine. So what’s left? Maybe 64MB of data that gets written or updated – the DNS log, DHCP leases, maybe a cache. But none of that is very big, and none of it needs to be persistent across (rare!) reboots. All the writable data on the system lives in /var.

FreeBSD supports a variety of diskless operation modes, so I went looking what is possible there. Turns out /var on diskless systems can be treated specially, and that is just what I need.

In rc.conf there are dozens of system-configuration variables that you can set. It’s still old-school SysV initialization, and I like it like that. Here is what I added to /etc/rc.conf:

varmfs=YES
varsize=256M
varmfs_flags='-S -k /var.md/'

The configuration says to use a memory-disk for /var, that it should be 256MiB large (plenty, and still acceptable within the 3GiB memory size of the H6), without softupdates (a BSD UFS tweak) and using /var.md as “skeleton”. That means that the memory disk is populated from the contents of /var.md when it is created.

With this setup, I have writable storage that is not persistent and that does not wear our the SD card, with minimal impact on the rest of the system – and it is simple to switch back if necessary.