ZFS Without GRUB

Canonical has announced changes to how Ubuntu handles GRUB and Secure Boot for ZFS root installations. The details are still unfolding, but the direction is clear: the combination of GRUB + Secure Boot + ZFS on root is becoming harder to maintain, and Canonical may stop supporting it.

If you run ZFS on root today with GRUB and Secure Boot, this affects you. If you're planning to, it affects you more.

This page explains what Secure Boot actually does, why it matters for ZFS, what the GRUB problem is, and how to make your own informed decision — regardless of what any single vendor decides to do.

Secure Boot is a UEFI firmware feature that verifies every piece of code in the boot chain before executing it. The goal: prevent malware from running before the operating system loads.

Here's how the chain works:

Each layer trusts only the next signed component. Microsoft signs the shim (because UEFI firmware ships with Microsoft's keys). The distro vendor signs GRUB and the kernel. Third-party kernel modules — like ZFS — need to be signed separately via Machine Owner Key (MOK) enrollment.

Why It Exists

Before Secure Boot, a rootkit could replace your bootloader with a compromised version. Your system would boot normally, but the attacker had control before the OS even loaded. Secure Boot closes that attack vector by ensuring only cryptographically verified code runs.

The Trade-Off

Security comes at the cost of flexibility. Every kernel module you load must be signed. Every bootloader change requires re-signing. Out-of-tree modules like ZFS — which are not part of the mainline Linux kernel — need extra steps to work with Secure Boot.

ZFS is not just a filesystem. It's a volume manager and filesystem combined. When you run ZFS on root, ZFS manages:

• The boot filesystem — where your kernel and initramfs live
• Boot environments — snapshot-based rollback of your entire OS
• Dataset hierarchy — separate datasets for /home, /var, /docker, etc.
• Encryption — native ZFS encryption at the dataset level

For all of this to work, the bootloader must understand ZFS. It needs to read ZFS pools, enumerate boot environments, and load the kernel from a ZFS dataset.

GRUB can do this — it has a ZFS module. But maintaining GRUB's ZFS support alongside Secure Boot signing requirements is where the complexity explodes.

GRUB is a general-purpose bootloader that tries to support every filesystem, every architecture, and every boot scenario. For ZFS, this creates several problems:

1. Signing Complexity

GRUB's ZFS module must be signed as part of the GRUB binary. Every time ZFS changes its on-disk format, GRUB's ZFS module must be updated and re-signed. Canonical must coordinate this across their signing infrastructure, Microsoft's shim trust chain, and ZFS upstream releases.

2. Boot Environment Blindness

GRUB can read ZFS, but it doesn't truly understand ZFS boot environments. It generates static grub.cfg entries. When you create a new boot environment via zfs snapshot + zfs clone, GRUB doesn't automatically know about it. You need update-grub or manual configuration.

3. Maintenance Burden

Canonical has to maintain patches to GRUB for ZFS support, keep them compatible with Secure Boot signing, and handle the MOK enrollment workflow for users who install ZFS DKMS modules. This is a significant ongoing engineering cost for a feature that affects a subset of users.

What This Means for You

If you currently run Ubuntu with ZFS on root, GRUB, and Secure Boot enabled, you are dependent on Canonical's willingness to maintain this combination. If they drop it, your options are:

1. Disable Secure Boot (reduces security)
2. Stop using ZFS on root (loses boot environments, snapshots, etc.)
3. Switch to a bootloader that's purpose-built for ZFS

Option 3 is the right answer.

ZFSBootMenu is a bootloader designed from the ground up for ZFS. It replaces GRUB entirely.

Why ZFSBootMenu Solves the Problem

• No GRUB dependency — ZFSBootMenu talks to ZFS directly. No ZFS module inside GRUB to maintain or sign.
• Automatic boot environment detection — create a snapshot, it appears in the boot menu automatically. No update-grub.
• Single EFI binary — one file on the EFI System Partition. Simple, auditable, replaceable.
• Distro-independent — works with Ubuntu, Debian, Fedora, CentOS, Arch, any distro. Your boot chain doesn't depend on your distro vendor's signing decisions.
• Secure Boot compatible — ZFSBootMenu can be signed with your own keys or enrolled via MOK. You control the trust chain, not a vendor.

kldload uses ZFSBootMenu by default. Every installation — Ubuntu, Debian, CentOS, Fedora, Rocky, RHEL, Arch — boots via ZFSBootMenu with ZFS on root. No GRUB involved.

Here's how to take control of your ZFS boot chain today:

Quick Start

1. Download kldload (free, BSD-3-Clause)
2. Boot the ISO — USB or VM
3. Select your distro (Ubuntu, Debian, CentOS, etc.)
4. Select the Core profile
5. Install — ZFS on root with ZFSBootMenu is automatic
6. Export to your preferred format
7. Feed to Packer or deploy directly

Total time: under 15 minutes. You now have a ZFS-on-root image with a boot chain that doesn't depend on GRUB, Canonical, or anyone else's signing decisions.

Canonical's decisions about GRUB and Secure Boot are Canonical's to make. They have their reasons, their constraints, and their engineering priorities. We're not here to tell you they're wrong.

But you have choices.

You can choose a boot chain that doesn't depend on a single vendor's willingness to maintain it. You can choose a bootloader that was designed for ZFS from day one. You can choose to control your own signing keys, your own boot environments, and your own infrastructure.

The tools exist. They're free. They work today.

Make your own informed decision. We're here to help.