bsdinstall Gains Guided Root-on-ZFS Support, Years After ZFS Itself Landed
ZFS arrived in FreeBSD's base system in the late 2000s, but installing directly onto a ZFS root without manual command-line setup took years longer to become a guided installer option.
It’s easy to conflate two genuinely different milestones in FreeBSD’s ZFS history: the point where ZFS support existed in the kernel at all, and the much later point where the installer could actually set up a ZFS root filesystem for you, guided, without dropping to a shell and partitioning things by hand. These happened years apart, and the gap between them says something real about how large filesystem features actually reach ordinary users versus early adopters.
ZFS existing versus ZFS being installable
FreeBSD imported Sun’s ZFS code in the late 2000s, making it available as an importable, usable filesystem well before the installer had any concept of it. For a long stretch after that, actually running FreeBSD with its root filesystem on ZFS meant either installing normally onto UFS and converting afterward, or following a manual, command-line-driven process — creating the pool, the datasets, configuring the boot loader to find a ZFS root, and getting the on-disk layout exactly right — entirely outside of bsdinstall’s guided flow. Community documentation and forum threads from FreeBSD’s 9.x era explicitly describe this limitation: you could not install directly to a ZFS root pool from inside the default installer, and getting a working ZFS-root system meant following a manual process, often with meaningfully technical, easy-to-get-wrong steps around boot environment setup.
The installer catching up
bsdinstall eventually closed this gap with a genuinely guided option: modern versions of the installer present an “Auto (ZFS)” disk-partitioning choice alongside the traditional manual and auto-UFS options, which sets up a complete root-on-ZFS system — including boot environment support and, optionally, full-disk GELI encryption — without requiring the installing user to type a single zpool or zfs command themselves. This is the feature that actually made root-on-ZFS a mainstream, default-feeling choice for new FreeBSD installations rather than something reserved for users already comfortable enough with ZFS’s command-line tools to set it up manually.
Why the gap took years to close
Root-on-ZFS is meaningfully more involved for an installer to automate correctly than root-on-UFS: it has to handle pool creation, dataset layout decisions (separate datasets for /var, /tmp, and elsewhere are common ZFS-on-root conventions, each with its own reasoning), boot loader configuration that correctly understands ZFS’s on-disk structure well enough to find and boot a kernel from it, and — for the encryption option — key management during the install process itself. Automating each of those correctly, and covering the range of disk layouts and boot firmware (BIOS versus UEFI) users would actually have, is a larger and more failure-sensitive engineering task than the equivalent for UFS, which is a large part of why the feature arrived as a mature, trustworthy installer option only after ZFS itself had already been production-proven in FreeBSD for a considerable stretch of real-world use.
The pattern worth remembering
This same shape — a technology becomes available and usable by technically confident users well before it becomes a default, guided option for everyone else — recurs across FreeBSD’s history and well beyond it. ZFS’s own arc from “importable but manual” to “a default installer choice” is a specific, well-documented instance of a very general pattern: the hard part of shipping a major new filesystem is rarely just making it work, it’s making it safe and simple enough to hand to an installer wizard without an expert standing over the process.
Sources: