| pick your distro, get ZFS on root
kldload — your platform, your way, free
Source
The Recipe

What kldload actually does, step by step.

No magic. No proprietary automation platform. Just a sequence of well-understood steps, executed in the right order. Here's the recipe for turning a blank disk into a running ZFS system. This is exactly what the kldload installer does. You could do it by hand. kldload just automated it.

Step 1: Partition the disk

Two partitions. First: a 512MB EFI System Partition (FAT32) for the bootloader. Second: everything else, formatted as a ZFS pool. That's it. No swap partition (ZFS can handle swap as a zvol if needed). No /boot partition (ZFSBootMenu reads kernels directly from ZFS).

You're dividing the land. A small lot for the mailbox (EFI), and the rest for the house (ZFS).
Traditional installers create 3-5 partitions: EFI, /boot (ext4, because GRUB can't reliably read ZFS), swap, root, maybe /home. That's five failure points, five things to resize, five things to back up separately. kldload creates two: EFI and ZFS. Everything else is a dataset inside the pool. Datasets are free, flexible, and don't require repartitioning. You'll never run resize2fs again.

Step 2: Create the ZFS pool and datasets

Create rpool with LZ4 compression, 4K sector alignment, and POSIX ACLs. Then create the dataset hierarchy: rpool/ROOT/default (your root filesystem), rpool/home, rpool/var, rpool/var/log. Each dataset can have independent snapshot and quota policies.

Building rooms in the house. The living room (root), bedrooms (home), utility room (var). Each room has its own thermostat.
Why separate datasets instead of just directories? Because /var/log as a dataset means a runaway log can't fill your root filesystem. /home as a dataset means you can snapshot user data independently of the OS. /tmp as a dataset gets sync=disabled and exec=off — performance and security tuning that's impossible with a directory. Every dataset is a boundary: independent compression, independent snapshots, independent quotas, independent encryption. Directories can't do any of that.

Step 3: Install the base OS

For Debian: debootstrap lays down a minimal root filesystem. For CentOS: dnf --installroot does the same. Then install the kernel, ZFS packages, and essential tools. Build the ZFS kernel module via DKMS so it matches your exact kernel version.

Moving the furniture in. Bed, kitchen table, fridge. The essentials before you worry about decoration.
This is where kldload is fundamentally different from "just install ZFS after." A traditional install puts the OS on ext4, then you apt install zfs-dkms, which downloads source, compiles against your kernel headers, and hopes nothing goes wrong. kldload does this at image build time — the module is compiled, signed with a MOK key, and embedded in the image before it touches a target machine. The kernel and the module are a matched pair. No compiler on the target. No DKMS in the boot path. No "it compiled fine on my machine but broke on yours." For FreeBSD, there's no DKMS at all — ZFS is in the kernel natively. kldload downloads base.txz and kernel.txz, extracts them onto the pool, and loader.efi handles the rest.

Step 4: Build the initramfs

The initramfs needs the ZFS module baked in so the kernel can mount the ZFS root filesystem at boot. On Debian, zfs-initramfs handles this. On CentOS/RHEL, zfs-dracut. The initramfs also gets the machine's hostid so ZFS can identify its pools.

Packing a go-bag. It has everything you need to get from the front door (firmware) to your bedroom (root filesystem) in the dark.

Step 5: Install the bootloader

Copy the ZFSBootMenu EFI binary to the EFI System Partition. Register it with the firmware via efibootmgr. Install a backup copy at the UEFI fallback path so it boots even if the firmware forgets the boot entry. Write /etc/fstab for just the EFI partition — ZFS datasets are mounted by zfs-mount.service, not fstab.

Putting up the address sign and making sure the GPS knows where you live.

Step 6: Export and reboot

Cleanly export the ZFS pool so it can be imported fresh on first boot. Write the zpool.cache so the pool imports quickly. Enable ZFS systemd services. Power off. Remove the USB. Boot from disk.

You now have a ZFS-on-root Linux system with boot environments, automatic snapshots, transparent compression, and a filesystem that will never silently corrupt your data.

Locking up the construction site, handing over the keys, and moving in.

What you actually have after Step 6:

It's not just "a Linux install with ZFS." It's a machine where:

  • Every file is checksummed — silent corruption is detected and repaired automatically on mirrors
  • Every write is compressed — you're using 30-50% less disk than the same data on ext4
  • The entire OS is a dataset — snapshot it, clone it, roll it back, replicate it to another machine
  • Boot environments let you undo a kernel upgrade by picking the old snapshot from a menu
  • zfs send replicates the whole system — OS, data, config — to a DR node in one command
  • WireGuard is ready — the module is loaded, create a tunnel whenever you need one
  • The factory snapshot is your known-good baseline — you can always get back to this moment

A traditional installer gives you an OS. This gives you an OS with superpowers baked in from birth. The difference isn't what you install. It's what's available the moment you boot.

Every step above is a function in the source code k_install_zfs_storage(), k_bootstrap_base(), k_install_bootloader() — readable bash functions with comments. Fork the repo. Read them. Modify them. That's the point.
← It's not just about receiving. You have to send, too. Frequently Asked Questions →