zbm.prefer=<pool>

zbm.prefer=<pool>!

zbm.prefer=<pool>!!

zbm.import_policy=hostid

zbm.import_policy=strict

zbm.import_policy=force

NOTE:

echo 0 > /sys/module/spl/parameters/spl_hostid

zbm.sort_key=name

zbm.sort_key=creation

zbm.sort_key=used

zbm.timeout=0 | zbm.skip

zbm.timeout=-1 | zbm.show

zbm.timeout=<positive integer>

The hookspec parameter takes the form

device//path

where device is either a regular device node (e.g., /dev/sda) or other partition identifier recognized by mount(8) (e.g., LABEL=<label> o UUID=<uuid>). The path component following // represents the location of a directory with respect to the root of the filesystem on device. For example, if a partition with a UUID of DEAD-BEEF is mounted at /boot/efi on a running system and the hook root should refer to the path

/boot/efi/EFI/zfsbootmenu/hooks,

the corresponding hook specification should be

zbm.hookroot=UUID=DEAD-BEEF//EFI/zfsbootmenu/hooks

on the ZFSBootMenu command line. Note that any kernel modules necessary to mount the specified filesystem must be present in the ZFSBootMenu image. (For example, mounting a FAT32 filesystem may require that vfat.ko, fat.ko, nls_cp437.ko and nls_iso8859_1.ko be added to the image.)

Within the hook root, create subdirectories early-setup.d, setup.d, load-key.d, boot-sel.d or teardown.d to hold hooks for the respective stages of hook execution. ZFSBootMenu will mount the device named by the hook specification, look for the individual hook directories, and copy any files found therein into its own memory-backed root filesystem. The copy is not recursive and further subdirectorie are ignored. Note that, because ZFSBootMenu copies these scripts into its standard hook paths at each boot, it is possible to "mask" a script explicitly included in the ZFSBootMenu image by including an external hook script with the same name in the appropriate directory.

NOTE: The hooklist argument MUST NOT contain spaces and MUST NOT be enclosed in quotes.

The use of full device paths other than descendants of /dev/disk/ is fragile and should be avoided. The delay interval between device checks can be controlled by zbm.retry_delay.

If the identifier does not match any kernels, the latest kernel will be chosen as a fallback.

zfs set org.zfsbootmenu:commandline="zfs.zfs_arc_max=8589934592" zroot
zfs set org.zfsbootmenu:commandline="%{parent} elevator=noop" zroot/ROOT
zfs set org.zfsbootmenu:commandline="loglevel=7 %{parent}" zroot/ROOT/be

will cause ZFSBootMenu to interpret the kernel command-line for zroot/ROOT/be as

loglevel=7 zfs.zfs_arc_max=8589934592 elevator=noop

Never set the root= argument; ZFSBootMenu always sets this option based on the selected boot environment.

off

on

The default prefix is root=zfs: for most boot environments. Environments that appear to be Arch Linux will use zfs= by default, while those that appear to be Gentoo or Alpine will use a default of root=ZFS=. The root prefix is generally determined by the initramfs generator, and the default is selected to match the expectation of the preferred initramfs generator on each distribution.

Set this property to override the value determined from inspecting the boot environment.

Normally, when ZFSBootMenu attempts to load encryption keys for a boot environment, it will attempt to look for a key file at the path specified by the keylocation property on the encryptionroot for that boot environment. If that file does not exist, and keyformat=passphrase is set for the encryptionroot (or keylocation=prompt), ZFSBootMenu will prompt for a passphrase to unlock the boot environment. These passphrases entered are not cached by default.

When org.zfsbootmenu:keysource is a mountable ZFS filesystem, before prompting for a passphrase when keylocation is not set to prompt, ZFSBootMenu will attempt to mount <filesystem> (unlocking that, if necessary) and search for the key file within <filesystem>. When <filesystem> specifies a mountpoint property that is not none or legacy, the specified mount point will be stripped (if possible) from the beginning of any keylocation property to attempt to identify a key at the point where it would normally be mounted. If no file exists at the stripped path (or the mountpoint specifies none or legacy), keys will be sought at the full path of keylocation relative to <filesystem>. If a key is found at either location, it will be copied to the initramfs. The copy in the initramfs will be used to decrypt the original boot environment. Copied keys are retained until ZFSBootMenu boots an environment, so a single password prompt can be sufficient to unlock several pools with the same keysource or prevent prompts from reappearing when the pool must be exported and reimported (for example, to alter boot parameters from within ZFSBootMenu).

ZBM_LOCKED_FS

ZBM_ENCRYPTION_ROOT

ZFSBootMenu will abandon its attempt to unlock the filesystem and indicate success if the filesystem is not locked after execution of any load-key hook. If the filesystem remains locked after hook execution, ZFSBootMenu will continue with its standard unlocking attempt.

Teardown hooks will be installed from the directory ${zfsbootmenu_hook_root}/teardown.d. These hooks will be executed after the kernel for a selected environment has been loaded and is launching via kexec is imminent. Some hardware initialized by the ZFSBootMenu kernel may not be properly reinitialized when a boot environment is launched; teardown hooks may be useful to unbind drivers from problematic hardware or remove associated kernel modules.

Boot-selection and teardown hooks each have access to three environment variables that describe the boot environment that is about to be launched:

ZBM_SELECTED_BE

ZBM_SELECTED_KERNEL

ZBM_SELECTED_INITRAMFS

Additionally, boot-selection hooks will have access to a fourth environment variable:

ZBM_SELECTED_MOUNTPOINT

Teardown hooks should never assume that the filesystem named in ZBM_SELECTED_BE is currently mounted. In addition, no teardown hook should assume that the ZFSBootMenu environment is in a consistent operating state. ZFSBootMenu may have exported some or all pools prior to executing teardown hooks.

In general, it is not possible to cleanly abort a boot attempt from boot-selection or teardown hooks. However, a boot-selection or teardown hook may take control of the boot attempt by implementing its own kexec load and execution without returning to ZFSBootMenu. This may be useful, for example, to allow ZFSBootMenu to select a boot environment and then restructure the boot process to launch a Xen kernel with the selected environment configured as dom0.