bsdinstall Gains Guided Root-on-ZFS Support, Years After ZFS Itself Landed

FreeBSD reached two distinct ZFS milestones six years apart. FreeBSD 7.0-RELEASE, announced on February 27, 2008, included support for Sun’s ZFS. FreeBSD 10.0-RELEASE, announced on January 20, 2014, added guided root-on-ZFS installation to bsdinstall. The later feature turned a technically possible storage layout into a supported installer workflow with choices for disks, pool topology, partitioning, encryption, and sector size.

ZFS support arrived with FreeBSD 7.0

The FreeBSD 7.0 release notes list ZFS support for amd64, i386, and pc98. That made the filesystem available to FreeBSD users, but “the operating system supports ZFS” is not equivalent to “the standard installer can build a bootable ZFS-root system.” A data pool mounted after boot has fewer integration requirements than the filesystem containing the kernel, userland, configuration, and boot-time state.

Root-on-ZFS had to satisfy the whole boot chain. Disk partitions needed suitable boot code; loaders needed to locate files inside the pool; the system had to import the right pool and mount its datasets in the right order; and the installed configuration had to reproduce those decisions after reboot. Experienced users could assemble such systems manually, but doing so demanded more storage and boot knowledge than choosing a filesystem in a guided menu.

bsdinstall first replaced sysinstall

FreeBSD introduced bsdinstall before it gained the ZFS wizard. The new installer replaced the aging sysinstall framework, and FreeBSD 10.0 later removed sysinstall and its supporting tools from base. This chronology prevents another common conflation: the arrival of bsdinstall itself did not automatically deliver guided root-on-ZFS.

An installer is an integration layer, not simply a front end for zpool create. It must discover disks safely, avoid overwriting an unselected device, create partitions for the active firmware and boot scheme, establish predictable dataset properties, install boot code, write configuration, extract the system, and give the user a final opportunity to stop before destructive changes begin.

The FreeBSD 10.0 release notes document the feature directly: bsdinstall(8) could now install ZFS on the root filesystem through a single configuration menu. The listed controls included which drives to use, the ZFS RAID level appropriate to the selected disk count, GPT or MBR partitioning, GELI encryption, forced 4K sectors, and the pool name. The release notes identify the implementation as source revision r256361.

Those options reveal why this was more than a “use ZFS” checkbox. A stripe, mirror, and RAID-Z arrangement have different capacity and failure properties. Forcing 4K sectors can prevent an apparently functional pool from suffering an avoidable alignment penalty. GELI inserts block-device encryption below ZFS and requires passphrase handling during installation and boot. The installer had to translate each selected policy into a coherent, bootable disk layout.

What the current Auto (ZFS) workflow promises

The current FreeBSD Handbook describes Auto (ZFS) as creating a root-on-ZFS system with optional GELI encryption and support for boot environments. Its guided workflow operates on whole disks and warns that selected contents will be erased. The menu can configure the pool name, disk set and top-level virtual-device type, partition scheme, swap, disk and swap encryption, 4K-sector behavior, and additional pool properties.

The Handbook also defines an important boundary: the automatic installer supports one top-level virtual device, except for stripe mode. More elaborate pool designs belong in the installer’s shell workflow. Guided support therefore reduces common setup errors, but it is not a universal graphical composer for every valid ZFS topology.

Boot-environment support deserves careful wording as well. ZFS datasets and snapshots make boot environments practical, and the installer’s dataset-oriented root layout supports that model. The original 10.0 release-note entry, however, documents the root-on-ZFS configuration menu and its storage controls; it should not be rewritten to imply that every later boot-environment tool or current menu behavior appeared fully formed in the first implementation.

GELI and native ZFS encryption are different layers

FreeBSD 10.0’s guided option named GELI, which encrypts the underlying provider before ZFS uses it. OpenZFS later gained native dataset encryption, a different design that can encrypt selected datasets while leaving other pool metadata or datasets accessible according to their configured keys. Calling the historical installer option merely “ZFS encryption” blurs that distinction.

The current installation chapter still documents optional GELI disk encryption in the guided workflow. Users should follow the documentation for the exact FreeBSD release they are installing, because installer choices, boot-loader capabilities, and OpenZFS features evolve. A historical article can accurately describe the 10.0 milestone without promising that every release exposes identical encryption controls.

Why the six-year gap was reasonable

Filesystem import and default installation are different assurance levels. The first makes a technology available for testing and deployment by informed administrators. The second asks release engineering to encode safe defaults across disk counts, firmware modes, sector sizes, encryption choices, pool topologies, and destructive confirmation paths.

The years between 7.0 and 10.0 also allowed ZFS integration, boot support, operational knowledge, and installer infrastructure to mature. By 2014, FreeBSD could offer a repeatable guided path instead of requiring each new user to reconstruct a manual recipe. That lowered the expertise threshold while keeping advanced shell-based layouts available.

The milestone is usability backed by integration

FreeBSD 7.0 established that ZFS was part of the supported operating-system story. FreeBSD 10.0 made a ZFS root an explicit installation path, with auditable choices and a final destructive-action boundary. The achievement was not that bsdinstall issued a few storage commands. It was that the installer coordinated bootability, partitioning, pool construction, dataset layout, and optional GELI encryption into one supported transaction.

Keeping those milestones separate makes the history clearer: ZFS first became available, root-on-ZFS remained an expert installation task, and guided support later made it a normal choice for a fresh FreeBSD system.

Related:

Sources: