Is ZFSBootMenu distribution-agnostic, and how is it deployed?

Yes. ZFSBootMenu is described in its documentation as distribution-agnostic: it is a small, self-contained Linux system that locates other Linux kernels and initramfs images inside ZFS filesystems and boots a chosen one with kexec. Because it does not depend on a particular distribution's boot chain, it can present boot environments from different distributions, different versions of one distribution, or earlier snapshots of a common root. Deployment is equally flexible: you can install it locally, build it in a container, or use prebuilt EFI executables after signature verification.

What “distribution-agnostic” means in practice

ZFSBootMenu does not boot a fixed root filesystem. At startup it imports healthy ZFS pools, identifies candidate boot environments, and either automatically boots a preferred environment or lets you choose one from a menu. The documentation lists these possible boot environments:

• different versions of a Linux distribution;
• earlier snapshots of a common root;
• entirely different distributions.

It also allows snapshot manipulation in the pre-boot environment, and, for advanced users, bootstrapping a system installation via zfs recv. The practical requirement is that the kernels and initramfs images you want to boot live in ZFS filesystems that ZFSBootMenu can find and import — not that they come from one specific distribution.

How the boot process works

The documented flow is:

1. Boot a ZFSBootMenu image — as a self-contained UEFI application, or as a dedicated Linux kernel and initramfs — via direct EFI booting, an EFI boot manager such as rEFInd, a BIOS bootloader such as syslinux, or another method.
2. ZFSBootMenu finds all healthy ZFS pools and imports them, or imports only a specific pool if configured.
3. It selects a preferred boot environment:
   • If the command line specifies a pool preference and that pool is imported, the filesystem indicated by its bootfs property is preferred, if defined.
   • If no pool preference is given, or the preferred pool is not found, the bootfs property on the first-found pool is preferred, if defined.
4. If a suitable bootfs is identified, an interruptable countdown (10 seconds by default) starts to boot that environment automatically.
5. If no bootfs can be identified or the countdown is interrupted, a search begins (the documentation excerpt ends at this point).

Deployment options

The documentation groups deployment under “Easily Deployed and Extensively Configurable” and names these paths:

For prebuilt binaries, the documentation pairs the download with signature verification, so verify the signature before booting an image. Run-time behavior is configurable through command-line arguments and run-time configuration, which is where pool preference and similar settings are expressed.

Choosing an approach

• Use prebuilt EFI executables if you want the self-contained UEFI application path and are prepared to verify signatures first.
• Install locally if you want ZFSBootMenu integrated into an existing system's boot setup.
• Build in a container if you want to produce the image yourself in a controlled build environment.

All three lead to the same runtime behavior: pool import, boot-environment selection, and kexec into the chosen kernel. The documentation does not state pricing or login requirements for these resources, so check the site directly for access conditions.