Christopher Mosetick

ZFS: Armbian Linux

Status: Work in Progress – Safety scripts developed, deployed, and battle-tested on production hardware. Upstream contribution to the Armbian project is a future goal once the approach is fully stabilized.

The Problem

Armbian is a Linux distribution targeting ARM64 single-board computers. It does not currently ship with first-class ZFS support – the primary reason being that most ARM64 devices historically shipped with very limited RAM, and ZFS has meaningful memory requirements.

That is changing. A new generation of ARM64 devices now ships with up to 32 GB of RAM, making ZFS entirely practical for both home-lab and production workloads.

The Radxa Rock 5B+ is one example – a single-board computer available in configurations up to 32 GB RAM.

But the ecosystem hasn’t caught up. And here is where it gets important to understand some history: ZFS is not in the Linux kernel – not because of a technical limitation, but because of a licensing conflict.

ZFS was originally developed by Sun Microsystems and is licensed under the CDDL (Common Development and Distribution License). The Linux kernel is licensed under GPLv2. Lawyers at the Free Software Foundation and elsewhere have long argued these two licenses are incompatible – meaning ZFS cannot legally be distributed as part of the Linux kernel source tree.

The result is that ZFS must be installed as an out-of-tree kernel module via DKMS (Dynamic Kernel Module Support). This means the ZFS kernel module has to be rebuilt from source every time the kernel is upgraded – a process that is straightforward on a well-resourced x86 server, but fragile and error-prone on resource-constrained ARM64 hardware.

When that rebuild fails – or rebuilds for the wrong kernel – the system boots without ZFS modules. Any application depending on a ZFS pool at boot fails. If that pool holds a database or application data, the impact is immediate.

Why This Matters

In 2026, ZFS is one of the most battle-tested filesystems available on Linux. Most recent Ubuntu Server versions ship with packaging that handles kernel and ZFS updates properly.
Additionally, ARM64 hardware with sufficient RAM it is becoming more of a practical choice for running databases, backup targets, and application storage on lower-cost, lower-power hardware.

I’m proud to be pioneering the use of ZFS on lower power ARM64 devices, and helping to improve the distro-wide support for this useful filesystem with unrivaled features.

The gap is not in ZFS itself – it is in the integration layer: the scripts, hooks, and procedures that keep ZFS modules aligned with the running kernel across routine system maintenance.
This project is an attempt to close that gap for Armbian users.

Upstream contribution to the Armbian project is the current goal.

Bugs Found in Production

Bug 1 – Wrong Kernel Target (December 15, 2025)

During a routine apt upgrade on a RockPro64 (Armbian, RK3399 ARM64), the system upgraded from kernel 6.12.57-current-bcm2711 to 6.12.58-current-bcm2711. The safety rebuild script ran as expected – but rebuilt ZFS for the wrong kernel.

The script used uname -r to determine which kernel to target:

# WRONG: returns the currently running kernel, not the newly installed one
CURRENT_KERNEL=$(uname -r)

During an upgrade, the running kernel is still the old one. The new kernel was installed but never got ZFS modules built for it. The system printed a misleading success message and was left unsafe to reboot:

update-initramfs: Generating /boot/initrd.img-6.12.58-current-bcm2711
[ZFS] Rebuilding for kernel 6.12.57-current-bcm2711 (ZFS 2.3.5)...
[ZFS] ✓ Rebuild successful

Verification confirmed the damage:

$ ls /lib/modules/6.12.58-current-bcm2711/kernel/zfs/
ls: cannot access: No such file or directory

$ dkms status
<empty>

Fix: Replaced uname -r with a loop over all directories in /lib/modules/, checking each installed kernel for missing ZFS modules and rebuilding only where needed.

Bug 2 – APT Hook Over-Triggering (February 12, 2026)

The APT hook used DPkg::Post-Invoke, which fires on every package operation – not just kernel upgrades. Installing an unrelated package like sysstat triggered a full DKMS rebuild, which overwrote working ZFS modules with incomplete builds.

This destroyed ZFS functionality after routine package installations.

Fix: Split into two hooks:

  1. A detection hook that sets a flag file only when kernel or ZFS packages are touched
  2. A conditional hook that runs only when the flag file exists

Current Approach

After two rounds of fixes, the architecture is deliberately conservative:

APT hooks do backups only – no automatic DKMS rebuilds.

When a kernel or ZFS package is upgraded, the hooks:

DKMS rebuilds for the new kernel are performed manually, with the operator in control.
On ARM64 hardware, this matters: the currently fanless RK3399 SoC in the RockPro64 hit 90–91°C during parallel DKMS builds and rebooted mid-build. The safe build command is single-threaded:

sudo MAKEFLAGS="-j1" dkms install zfs/2.4.0 -k <new-kernel-version>

Production Deployment

Running on a RockPro64 (Armbian 25, Ubuntu 24.04 base, aarch64):

The same RockPro64 is also a test system for the tailscaled dedicated logging work I’m doing, running Armbian’s zram-based /var/log with the custom sync timer.

References

Jeff Bonwick led the original ZFS development at Sun Microsystems. He and his team designed ZFS from the ground up with data integrity, pooled storage, and copy-on-write semantics as first-class goals – a significant departure from traditional filesystem design of the time.

Brian Behlendorf has been a primary maintainer and driving force behind the OpenZFS project, which brought ZFS to Linux and other platforms under a consolidated open source effort. The ZFS on Linux work that makes this project possible exists in large part due to his sustained contributions.