zfsbootmenu is implemented as a Dracut module to provide an experience similar to FreeBSD's bootloader, for Linux distributions. In broad strokes, it works as follows:
* Via GRUB, direct EFI booting, etc, boot a Linux kernel along with an initramfs containing ZFS Boot Menu
* Look for `zfsbootmenu` on the kernel command line
* Optionally specify a default pool (if multiple are present)
* Find all healthy pools and then import them
* If a specific pool was set, look for the bootfs pool value. Prefer this boot environment.
* If no pool was defined on the command line, use the bootfs value on the first-found pool
* If a bootfs value is defined, start a 10 second countdown to boot that environment with the highest kernel found in /boot
* If no bootfs value is defined, find every filesystem that mounts to / with a /boot directory, and find every kernel. Prompt via fzf.
* Load the kernel, initramfs and the kernel command line defined in the `org.zfsbootmenu:commandline` property (or, as a fallback, `/etc/default/grub`) into memory via kexec
To ensure the boot menu can find your kernels, you'll need to ensure `/boot` resides on your ZFS file system. An example filesystem layout is as follows:
There are two boot environments created, identified by mounting to /. The environment that this system will boot into is defined by the `bootfs` value set on the `zroot` zpool.
On start, ZFS Boot Menu will find the highest versioned kernel in `zroot/ROOT/void.2019.11.01/boot`, confirm that a matching initramfs is present, and default to booting the OS with that.
Kernel command-line arguments should be set by setting the ZFS property `org.zfsbootmenu:commandline` on each boot environment. If the property is not defined for a boot environment or its parents, command-line arguments will be taken from the `GRUB_CMDLINE_LINUX_DEFAULT` variable in the file `/etc/default/grub` of the boot environment if the file exist and the variable is defined. Do not set any `root=` or any other pool-related options in the kernel command line; these will be filled in automatically when a boot environment is selected.
Because ZFS properties are inherited by default, it is possible to set the `org.zfsbootmenu:commandline` property on a common parent to apply the same arguments to multiple environments. Setting the property locally on individual boot environments will override the common defaults.
Each boot environment should have `/boot` live on the ZFS filesystem. Using the above example, `zroot/ROOT/void.2019.11.01` would contain `/boot` with any kernel/initramfs pairs.
Once `/boot` is backed by ZFS in a boot environment, you'll need to install the boot menu files. Typically, EFI partitions are mounted to `/boot/efi`, and contain a number of sub-directories. In this example, `/boot/efi/EFI/void` holds the ZFS Boot Menu kernel and initramfs.
With this layout, you'll now need a way to boot the kernel and initramfs via EFI. This can be done via a manual entry set via efibootmgr, or it can be done with rEFInd.
`rEFInd` is considerably easier to install and manage. Refer to your distributions packages for installation. Once rEFInd has been installed, you can create `refind_linux.conf` in the directory holding the ZFS Boot Menu files (`/boot/efi/EFI/void` in our example):
This file will configure `rEFInd` to create two entries for each kernel and initrams pair it finds. The first will directly boot into the environment set via the `bootfs` pool property. The second will force ZFS Boot Menu to display an environment / kernel / snapshot selection menu, allowing you to boot alternate environments, kernels and snapshots.
ZFS Boot Menu currently understands the following options:
*`spl_hostid=` used to set the system hostid if you are using a pre-built initramfs from the release page.
*`force_import=0|1` set to `1` to attempt to force import all pools on the system. Use with caution!
*`read_write=0|1` set to `1` to enable writes to pools when importing. Pools are imported read-only by default as a safety precaution.
*`timeout=`
* A value of `0` will result in the system immediately booting from the pool configured in the `bootfs` pool property
* A value of `-1` will result in the system displaying a boot menu.
* Any other positive value will show a countdown timer to boot the environment configured under `bootfs`, otherwise it will default to a boot menu.
*`""|zfsbootmenu|zfsbootmenu:|zfsbootmenu:POOL=zroot` The first three values are functionally identical. The fourth can be used to prefer a pool if multiple are present in the system.
`bin/generate-zbm` can be used to create an initramfs on your system. It ships with void-specific defaults in `etc/config.ini`. To create an initramfs, the following additional tools/libraries will need to be available on your system:
If you want to create an unified EFI file (kernel, initramfs, command line), the following additional tools will be needed:
* gnu objcopy (typically packaged as binutils)
* linuxx64.efi.stub (typically packaged as gummiboot)
Your distribution should have packages for these already.
## config.ini
`/etc/zfsbootmenu/config.ini` is used to control the behavior of generate-zbm. An example is documented below.
```
[Global]
ManageImages=0
DracutConfDir=/etc/zfsbootmenu/dracut.conf.d
[Kernel]
CommandLine="ro quiet loglevel=0"
[Components]
ImageDir=/boot/efi/EFI/void
Versioned=1
Copies=3
[EFI]
ImageDir=/boot/efi/EFI/void
Versioned=1
Copies=0
```
### Global
*`ManageImages` Set this to 1 to allow generate-zbm to perform any actions (creation, removal of old files, etc)
*`DracutConfDir` Set this to the location of the dracut configuration director for ZFS Boot Menu. This *CAN NOT* be the same location as the system `dracut.conf.d`, as the configuration files there directly conflict with the creation of the bootmenu initramfs.
### Kernel
*`CommandLine` If you're making a unified EFI file, this is the command line passed to the module. Refer to [Command line options](README.md#command-line-options).
### Components
*`ImageDir` This is the destination directory for the initramfs and kernel.
*`Versioned` Set to 1 to create versioned files. Set to 0 to disable a version suffix, which is useful if you have static bootloader entries pointing to ZFS Boot Menu.
*`Copies` This controls the number of copies to keep, in addition to the file that is currently being created.
### EFI
*`ImageDir` This is the destination directory for the unified EFI file.
*`Versioned` Set to 1 to create versioned files. Set to 0 to disable a version suffix, which is useful if you have static bootloader entries pointing to ZFS Boot Menu.
*`Copies` This controls the number of copies to keep, in addition to the file that is currently being created.
ZFS Boot Menu can import pools or filesystems with native encryption enabled. If your boot environments are not encrypted but say /home is, you will not receive a decryption prompt. To ensure that you can decrypt your pool to load the kernel and initramfs, you'll need to you have the filesystem parameters configured correctly.
It's critical that `keyformat` is set to `passphrase`, otherwise you'll be unable to enter the correct value in the boot loader. ZoL currently only supports one key, but it does have a behavior that we can exploit. If you configure the `keylocation` value to a file on disk, put your passphrase in that, and then put that file into the FINAL initramfs, you won't receive a second password prompt on boot. You'll then still receive a password prompt in the boot loader, since we can force a prompt for passphrase input.
For Dracut-based systems, this can be done by creating `/etc/dracut.conf.d/zol.conf` with the following contents:
```
install_items+=" /etc/zfs/zroot.key "
```
It's critical that you do not put this key file into the ZFS Boot Menu initramfs, since that file exists on an unencrypted volume - leaving your pool essentially wide-open.
When building a kernel command line to pass to the kexec'd kernel, the command line generated is always created for Dracut's ZFS module. Again, this will need to be modified based on the detected OS in the boot environment.
Both of the above issues are readily resolved by hopefully reading /etc/os-release from the boot environment and acting based on that.
