Kudos to everyone involved in this! Love everything about this. Using it on my notebook, on dedicated servers rented at Hetzner as well as on Hetzner-Cloud, as well on a bunch of dedicated servers in a rack. Solves almost all problems related to ZFS and Linux. Booting this from SYSLINUX works very well as well as UEFI - it's extensible and you can run it with the ZFS git version if you use the generate-zbm command. Saved my ass quite a few times already.
It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader.<p>That bootloader needs to mount a filesystem to find the kernel.<p>The kernel needs to mount the filesystem to run the system.<p>Each of those mount operations is done with different code, and normally each involves some config or search process to find the right disk/partition. If any of the searches finds the wrong partition or is misconfigured, you get a boot failure.<p>It really feels like the boot process is more complex than it needs to be, with more opportunities for failure than necessary.
I was looking at using this for my arch zfs-on-root setups, but I've instead just been hacking on /etc/grub.d/10_linux and /lib/initcpio/hooks/zfs to get the boot menu setup I want with grub. I like the simplicity of it this way with less dependencies (especially otherwise needing to use AUR for the zfsbootmenu build or use the pre-built binary blob).<p>One concern I had with zfsbootmenu was I couldn't figure out how to load microcode. With kexec, zfsbootmenu can only load one image and late loading microcode may be "dangerous" [1]. I don't know practically if that is a real security issue or not. I tried cat'ing my images together as below, but it still didn't work for me:<p><pre><code> mv initramfs-linux.img initramfs-linux.img.orig
cat intel-ucode.img initramfs-linux.img.orig > initramfs-linux.img
</code></pre>
[1] <a href="https://docs.kernel.org/arch/x86/microcode.html#why-is-late-loading-dangerous" rel="nofollow noreferrer">https://docs.kernel.org/arch/x86/microcode.html#why-is-late-...</a>
Nice project. In evaluating this for possible use, I have a question about workflow integration with snapshots. On gentoo-esque distros I believe there are two common configurations with ZFS, namely: (1) have a separate package repo (portage tree) ZFS dataset to the system root ZFS dataset and (2) to have them combined on one dataset.<p>In case 2 portage changes are automatically synchronized to system snapshots, but multiple system instances (VMs, diskless nodes, etc.) will have to redundantly update portage. However, in case 1 they are de-facto desynced and this can cause gentoo issues (yet saves duplicate network operations so is nominally desirable). Does ZFSBootMenu have a built-in system for managing ZFS root system snapshots with co-dependent dataset snapshot versions to enable case 1?
I used the FreeBSD version of this, I'm a shill at this point but I find nixos booting to an ephemeral tmpfs to be much better.<p>This wouldn't apply if you needed to have divergent state though, though it's hard to imagine a use case for that unhandled by fs snapshots.
Which Linux distribution provides this out of the box in its installer like FreeBSD does? ... along with optional LUKS encryption as FreeBSD offers optional GELI encryption.<p>I will wait ...
Been using this for arch <a href="https://github.com/prabirshrestha/simple-arch-installer">https://github.com/prabirshrestha/simple-arch-installer</a> and server <a href="https://github.com/prabirshrestha/simple-ubuntu-installer">https://github.com/prabirshrestha/simple-ubuntu-installer</a> with remote ssh unlock for zfs encryption.