I’ve downloaded the pre-compiled ZBM .efi to my EFI system partition, used efibootmgr to poke an entry into NVRAM, and successfully booted into it.
I can also boot into rEFInd which auto-detects said .efi and can chainload it, passing commandline arguments defined in /boot/refind_linux.conf. No boot stanzas in loader/entries needed.
Either way it sees my pool. I presume I can zpool set <property> to give ZBM whatever else it might need (I’m not there yet – I’m early in the process of moving an existing Fedora install onto ZFS).
So why would I want/need to “install” ZBM? I love this project but it needs a cheat-sheet for ADD-sufferers. The docs are good but it needs a single page to tie it all together. They have step-by-step instructions for new builds but nothing for brownfield conversions.
2nd part of this question: What’s actually required on the kernel command line to boot into a ZFS-on-root Linux system? Right now I have root=ZFS=tank/ROOT/fedora boot=zfs and all my datasets are canmount=noauto to lay the groundwork for a multi-distro ZfsBootMenu future. Does the above root= directive tell the system to go ahead and mount this pool anyway?
Does my pool need property bootfs set to tank/ROOT/fedora or should it remain blank? Seems counterproductive if I want to boot a distro in a different dataset.
I get to choose between zfs-mount.service or having zfs-mount-generator read /etc/zfs/zfs-list.cache? Why would I want the latter?
fstab will become obsolete when I’m finished?
I have so many questions about this “zero administration” filesystem…
Well, I’m not quite sure what you actually did. At this point, I think the most helpful response I’ve personally got on deck is to point you to the walkthrough I wrote for Klara:
If you tell me how what you did differs from how I documented a proper install, maybe we can go from there?
The directives on zfsbootmenu.org (along with this Klara article) are for greenfield standups, no? I’m brownfield (ie. already did a lift-and-shift of existing Fedora 43 to ZFS-on-root). It boots. It works. Using rEFInd.
I’m trying to figure out the right way to implement on a system where *nix was installed months ago. I haven’t seen documentation for brownfields (unless I’m looking right at it and not realizing).
Edit: just read the article more carefully. Regarding this test step:
Can I just put this BOOTX64.EFI on my EFI system partition, poke it into NVRAM with efibootmgr and call it a day? Does it make for a complete and fully functional ZFSbootmenu?
When looking for Linux kernels to boot, the only requirements are that: […] At least one of the scanned ZFS filesystems contains a /boot subdirectory that contains at least one paired kernel and initramfs.
Ugh. As part of my brownfield ZFS-on-root conversion I shitcanned the “Fedora way” of having an ext4 partition mounted at /boot and the EFI system partition mounted at /boot/efi.
These were consolidated to a single 3GB vfat partition with the appropriate “C12A....” typeguid as specified in UAPI docs and mounted at /boot. Essentially combining everything under /boot into a single bootable volume. EFI goodies are in an /EFI subfolder here.
For ZFSBootMenu my redesign was a mistake – it’s oblivious to vfat partitions and won’t search them for kernels, chainload to them, etc. What would be my /boot partition should now be a subdir in my ZFS pool. A reason to keep rEFInd in the boot chain as I might want to boot a distro on a non-ZFS volume. This is an unfortunate design choice – ZFSBootMenu is so close to being a super-rEFInd.
Amusingly (or maybe not), I never quite got rEFInd to work for me. I ultimately beat my head against efibootmgr until it made sense. I did discover one downside of using efibootmgr, when I flashed my BIOS it wiped out all of my entries. That caused some scrambling.
For ZBM, I’ve had decent luck building it. There was definitely documentation I discovered in building that made ZBM easier to use overall. In particular, you don’t need it to create an EFI image for you, you can separately load the initramfs and loader.
For efibootmgr this prebuilt command works for my laptop with an nvme drive, change to your own applicable mountpoint. After downloading per instructions
efibootmgr -c -d /dev/nvme0n1 -p 1 -L “ZFS Boot Menu” -l ‘\EFI\zbm\VMLINUZ.EFI’
This is how it’s supposed to break out when separating the initramfs from the compiled module. I haven’t gotten the build process completely consistent yet.
efibootmgr -c -d /dev/nvme0n1 -p 1 -L “ZFS Boot Menu compiled” -l ‘\EFI\zbm\vmlinuz.old-3.1.0_1’ --unicode ‘zbm.prefer=driver ro initrd=\EFI\zbm\initramfs-3.1.0_1.img quiet’
For me rEFInd has been superstar software. “It just works” as it finds bootable things on any and every drive and sticks them all in a menu. Simple flat text file for configuration and another for the kernel command line. No grub2-update brain damage. Understands vfat and ext4 and btrfs. I don’t maintain boot stanzas as I don’t need them. It finds everything I need and I can hide the stuff I don’t.
I couldn’t get the container to work. I launch it and… nothing. Now what? Still not sure why I need a poxy container just to gen up bootloader. Why am I having to “build” it in the first place? Give me an .efi and flat text files. Like rEFInd.
I was able to poke the ZFSBootMenu .efi into a UEFI boot slot along with a command line. efibootmgr has never been an issue for my mainboard.
I haven’t seen documentation for brownfields (unless I’m looking right at it and not realizing).