4 ms·

No, the ZFSBootMenu GUI does not do recursive operations on datasets / try to infer dependencies. However, there's a Bash shell that's a key press away with a f

No, the ZFSBootMenu GUI does not do recursive operations on datasets / try to infer dependencies. However, there's a Bash shell that's a key press away with a full set of OpenZFS binaries. You can also do a custom build of ZFSBootMenu and add in whatever additional scripts you'd like so that you can manage snapshot rollback/promotion as you see fit.

contingencies 3y ago
Thanks, that's what I suspected. After writing the grandparent comment I realised some people (in particular distro devs, I suspect) may treat kernel module datasets in a similar fashion, which provides a very similar use case. I wonder if - zfs dataset mountpoints and snapshot timings aside (both of which are already embedded in zfs) - it could be worth considering adding some zfs dataset properties as hints. One idea (half-baked) are "zfsbootmenu-boot-significant" = "true" for ZFSBootMenu guesses for adding a default inference of latest/greatest combos. Such a binary flag should elegantly cover both kernel module and portage tree type use cases, by indicating to ZFBootMenu that the dataset in question (and snapshots thereof) provide system-integrity critical system state and should be paired with a root dataset selection. ZFSBootMenu could then make appropriate assumptions around default selections / temporally proximal pairings. A second idea is a ZFS dataset property "zfsbootmenu-last-successful-boot" = "<datetime>" which combined with snapshot times should provide a useful inference. This could be rolled in to the ZFSBootMenu userland as an rc script updating the property on boot. Additional information such as "zfsbootmenu-last-successful-boot-options" and "zfsbootmenu-last-successful-boot-dataset-<dataset>-snapshot" could then be added. Alternatively or in addition a zfsbootmenu dataset could be added with more detailed log files. The result should be a cross-distribution (indeed cross-OS) methodology for the autonomous inference and validation of boot configurations involving multiple datasets in all use cases, a plethora of debugging information in a standard location, and even a mechanism to iteratively and autonomously fall back toward a functional boot configuration in the event of problems (which may be further improved using watchdog drivers, ie. if boot does not complete in X minutes, reboot and try another configuration).

contingencies 3y ago

Thanks, that's what I suspected. After writing the grandparent comment I realised some people (in particular distro devs, I suspect) may treat kernel module datasets in a similar fashion, which provides a very similar use case. I wonder if - zfs dataset mountpoints and snapshot timings aside (both of which are already embedded in zfs) - it could be worth considering adding some zfs dataset properties as hints. One idea (half-baked) are "zfsbootmenu-boot-significant" = "true" for ZFSBootMenu guesses for adding a default inference of latest/greatest combos. Such a binary flag should elegantly cover both kernel module and portage tree type use cases, by indicating to ZFBootMenu that the dataset in question (and snapshots thereof) provide system-integrity critical system state and should be paired with a root dataset selection. ZFSBootMenu could then make appropriate assumptions around default selections / temporally proximal pairings. A second idea is a ZFS dataset property "zfsbootmenu-last-successful-boot" = "<datetime>" which combined with snapshot times should provide a useful inference. This could be rolled in to the ZFSBootMenu userland as an rc script updating the property on boot. Additional information such as "zfsbootmenu-last-successful-boot-options" and "zfsbootmenu-last-successful-boot-dataset-<dataset>-snapshot" could then be added. Alternatively or in addition a zfsbootmenu dataset could be added with more detailed log files. The result should be a cross-distribution (indeed cross-OS) methodology for the autonomous inference and validation of boot configurations involving multiple datasets in all use cases, a plethora of debugging information in a standard location, and even a mechanism to iteratively and autonomously fall back toward a functional boot configuration in the event of problems (which may be further improved using watchdog drivers, ie. if boot does not complete in X minutes, reboot and try another configuration).