Kernels (/boot) stored in a different dataset than "/"

[LyingCak3]

ZBM assumes that /boot is part of the / dataset but a user could assign /boot to its own dataset. ZBM could be expanded to search for a dataset with mountpoint==/boot with canmount!=off that is the child to the / dataset, and/or a zfs property could be set, something like zfsbootmenu:boot_dataset_path, with the full path to the boot dataset to use.

[zdykstra]

This isn't a direction the project is currently willing to consider going. If you haven't already read this, please take a look at https://docs.zfsbootmenu.org/en/v2.3.x/general/bootenvs-and-you.html#boot-environments . It covers in detail why we enforce /boot as a directory of a boot environment.

[ahesford]

I'll note that, right out of the gate, the definition of a bootable filesystem becomes complicated by extra constraints (child of a filesystem with mountpoint=/) or the need to keep a property (org.zfsbootmenu:boot_dataset_path) synchronized with some second source of truth like mountpoint or /etc/fstab. Both of these are undesirable. The first case breeds "what if" scenarios that lead to us imposing one or another arbitrary restrictions on filesystem layouts. The second case is just fragile. Both cases either lead to significant parts of the ZBM UI functioning incorrectly or not at all; the alternative would be adding a bunch of hacky workarounds to restore functionality as people might expect for their configurations, but this is again fragile and unmaintainable.

If you really want to force this layout, set mountpoint=legacy and org.zfsbootmenu:active=on on your boot filesystem, manage its mounting with /etc/fstab, and ln -s . boot in your /boot. ZBM should find and boot the kernels, but be warned that lots of our menu options will fail to work as expected.

[LyingCak3]

Thank you for the quick reply and explanation of the product design. I understand why this request is desirable and appreciate the thoughtful explanation.