Does ZBM need to be "installed?" [SOLVED]

OpenZFS
1

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…

2

Please keep the previous post/thread title!

Someone might be searching for the same thing you did.

1 Like
3

Agreed. I restored the original title and added a [SOLVED] to the end.

1 Like
4

Actually I’m not all that happy with the answer I found regarding the “installation” of ZFSbootmenu vs. sticking the bare .efi into one’s ESP.

What does installing it do for me?

5

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?

6

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.:wink: 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:

wget –O /mnt/ZBMdrive/EFI/BOOT/BOOTX64.EFI https://get.zfsbootmenu.org/efi/recovery

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?

7

Oh, now I see. I’m afraid I’m in the same boat as you. I’ve tried to ZBM a pre existing system a few times but never had any luck with it.

If you come across (or write) those working docs, please share here!

8

Boot Environments and You: A Primer:

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.

Prebuilt .efi files are legit, it seems.