7 ms·

ZFSBootMenu

189 points by denysonique 3y ago

anotherhue 3y ago
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. 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.
- imiric 3y ago
  In what way do you find NixOS to be better? I'm actually thinking of going the other way, from NixOS to Void+ZFS. I've been using NixOS on 2 machines for a few months now, so I'm relatively new to it, but I still struggle with basic things, and don't really grok the Nix language. If ZFS+ZFSBootMenu can give me easy snapshotting and rollback functionality, then I might prefer it over NixOS. Sure, Nix does many more things besides snapshots, but for my use case it's the main benefit, so I wouldn't be missing much.
  - anotherhue 3y ago
    NixOS comes alive when you have ephemeral root. It's generating all of /var and /etc as it boots, from the config, and then just mounting your home directory at the end. So if I want to switch from pulse to pipewire, or some other messy change, I just edit the config, boot into it and it's like pulse never existed. If I don't like pipewire (I love pipewire) then I just choose the prior config option at boot and equally, pipewire never existed. I don't want my bootloader handling snapshots of my homedir, I can do that myself if I need (zfs auto snapshots, etc.). So with an ephemeral root, there is no other state to manage, making this kind of boot menu redundant. Think of it this way, you can carefully manage filesystem state using snapshots, or you can slap it all in the /nix store and have your system live assemble itself to spec on every boot. Like using git for your source tree instead of tar'ing up the whole thing everytime you make a scary change.
    - ahesford 3y ago
      I think you misunderstand what ZFSBootMenu does. It doesn't manage any snapshots. It refuses to do anything to any file system that isn't clearly marked as an operating system root. (There are a few well-defined criteria that must be met before ZBM will even attempt to determine if a filesystem has Linux kernels that it will allow you to boot.) Once it identifies one or more file systems that contain bootable Linux kernels, it allows the user to select a kernel from one of those file systems for booting. It also allows the user to enumerate snapshots of those bootable file systems and boot from them via ZFS cloning (with or without promotion) or a send-receive duplicate that avoids interdependencies. Yes, Nix manages a history of past system instances and NixOS modifies the bootloader to present each of these states as a bootable option. This maps loosely to the ability to elevate ZFS snapshots to boot environments in ZBM, but the functionality is not redundant. In fact, it isn't even a compatible alternative---we haven't found a good way to make ZBM boot NixOS. If you want NixOS, you're booting the NixOS way. Nix is a very interesting concept that offers several advantages. It also has drawbacks. For example, it can be inordinately complex to manage small deviations from upstream configurations that aren't represented by pre-existing options. (Ever try to add a single line to a PAM configuration file in Nix?) The Nix way of booting falls apart should you want to have multiple Linux distributions coexisting on a single pool. NixOS works best when you have complete buy-in. ZFSBootMenu doesn't care; if it can find kernels in the `/boot` directory of a ZFS filesystem, it will show you the filesystem and let you boot it.
  - istjohn 3y ago
    In case you weren't aware: Timeshift > System restore tool for Linux. Creates filesystem snapshots using rsync+hardlinks, or BTRFS snapshots. Supports scheduled snapshots, multiple backup levels, and exclude filters. Snapshots can be restored while system is running or from Live CD/USB. https://github.com/linuxmint/timeshift https://github.com/linuxmint/timeshift
nisa 3y ago
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.
- SushiHippie 3y ago
  May I ask how you use this on the dedicated server?
  - wongarsu 3y ago
    Hetzner's dedicated servers give you KVM access for stuff like tweaking your bios settings, installing an OS, or I guess using your boot menu. You have to request them via support ticket, but last time I did that I got it within 5 minutes, no questions asked. If you have your own server in a rack somewhere chances are you bought one with a similar web interface (IMPI/BMC/whatever your brand calls it) on a separate always-on NIC on the mainboard. https://docs.hetzner.com/robot/dedicated-server/maintainance/kvm-console/ https://docs.hetzner.com/robot/dedicated-server/maintainance...
    - codetrotter 3y ago
      When I installed FreeBSD on my Hetzner servers, I did so by booting the servers into the Linux based rescue mode and then I think I used dd to write the mfsBSD media onto one of the hard drives. This way I didn’t have to request KVM access for my servers. Perhaps a similar method can be used in order to install ZFSBootMenu
      - themoonisachees 3y ago
        Nice tip but if you fail your server is toast and that's an interesting support ticket.
dsp_person 3y ago
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). 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: mv initramfs-linux.img initramfs-linux.img.orig cat intel-ucode.img initramfs-linux.img.orig > initramfs-linux.img [1] https://docs.kernel.org/arch/x86/microcode.html#why-is-late-loading-dangerous https://docs.kernel.org/arch/x86/microcode.html#why-is-late-...
- E39M5S62 3y ago
  There shouldn't be any issues catting the real initramfs with microcode into another file. I do that, as does another ZBM developer. What do you see when you try it? I started ZBM years ago by hacking on the same grub script, then progressed to what it is now!
  - dsp_person 3y ago
    When I booted normally with the concatenated image (ensuring removing the original microcode img from the grub.cfg initrd command), I booted and I confirmed the microcode loaded with (dmesg | grep microcode). Then switching to ZBM, while it did boot with the concatenated image, I didn't see microcode loaded in dmesg.
aborsy 3y ago
Does ZFSBootMenu allow for entering encryption password remotely on encrypted root?
- nisa 3y ago
  yes you can add an ssh server or setup network in zfsbootmenu and use keylocation=https
- E39M5S62 3y ago
  Yes - both Dracut and mkinitcpio allow you to embed an SSH server in the ZFSBootMenu initramfs (dropbear, or OpenSSH) and connect to it. Once you connect, you can access the main interface and unlock any datasets prior to kexec. https://docs.zfsbootmenu.org/en/v2.2.x/guides/general/remote-access.html https://docs.zfsbootmenu.org/en/v2.2.x/guides/general/remote...
  - bpye 3y ago
    It's an aside - but I wish there was a way to do a kexec and keep the ZFS datasets unlocked. I don't think there's anything that stops it being technically possible, but I'm pretty sure it would require kernel mode changes...
    - E39M5S62 3y ago
      I just add the keyfile to the initramfs. It sits under an encryptionroot and is only readable by the root user, so it's largely as safe as native encryption can be.
prabir 3y ago
Been using this for arch https://github.com/prabirshrestha/simple-arch-installer https://github.com/prabirshrestha/simple-arch-installer and server https://github.com/prabirshrestha/simple-ubuntu-installer https://github.com/prabirshrestha/simple-ubuntu-installer with remote ssh unlock for zfs encryption.
londons_explore 3y ago
It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader. That bootloader needs to mount a filesystem to find the kernel. The kernel needs to mount the filesystem to run the system. 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. It really feels like the boot process is more complex than it needs to be, with more opportunities for failure than necessary.
- jeroenhd 3y ago
  There's not really a way around it unless you hardcode the bootloader rather than store it on disk. That said, there are only two steps in the modern boot process on a PC: the UEFI firmware loading a basic FAT driver and the kernel mounting the other filesystems. The UEFI bootloader can use the existing FAT driver to load the kernel and the initramfs which will use the same code to mount partitions. You can skip the UEFI bootloader and directly boot unified kernel images after putting them on the UEFI partition.
  - londons_explore 3y ago
    I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. That effectively removes all config from the process - and means that any disk with a uefi executable kernel can be booted without the mystery step of "lets try to figure out where we're booting from".
    - hackmiester 3y ago
      This does work inside of rEFInd, which can load a kernel EFI blob directly, and supply it args.
    - bpye 3y ago
      > I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. I think UEFI gives an EFI application (such as the Linux kernel) everything it would need for this already - but I guess Linux doesn't use it. The EFI application entry point includes a handle to your own image [0], and the EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID [1] protocol allows you to query the path it was loaded from. It is possible for an image to be loaded without a path, but it looks like EDK2 provides it at least [2]. [0] - https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-image-entry-point https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.h... [1] - https://uefi.org/specs/UEFI/2.10/09_Protocols_EFI_Loaded_Image.html#efi-loaded-image-device-path-protocol https://uefi.org/specs/UEFI/2.10/09_Protocols_EFI_Loaded_Ima... [2] - https://github.com/tianocore/edk2/blob/991515a0583f65a64b3a6fa354409c64e670a762/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1932 https://github.com/tianocore/edk2/blob/991515a0583f65a64b3a6...
deleted 3y ago
[deleted]
vermaden 3y ago
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. I will wait ...
- E39M5S62 3y ago
  It's okay for FreeBSD if Linux can do some things it can, and vice-versa. If you're that insecure about running FreeBSD after all this time, you'd do well to think about why that is.
  - assimpleaspossi 3y ago
    Running an unencumbered FreeBSD system will never make any user insecure.
- dizhn 3y ago
  OpenSuse Tumbleweed has btrfs+snapper and the installer sets it up automatically. I guess they could (technically) boot other operating systems but their focus is to boot into read only snapshots of the same OS. The same setup is possible on all Linux distros but the user has to set it up.
  - vermaden 3y ago
    Can BTRFS snapshots on OpenSUSE Tumbleweed (btrfs+snapper) provide same functionality as ZFS Boot Environments? Nope. Cite from System Recovery and Snapshot Management with Snapper for OpenSUSE Linux. ● Limitations A complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible. With ZFS Boot Environments you are bulletproof. With btrfs+snapper you are crossing fingers if it will work the way you need. Not the same thing.
contingencies 3y ago
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. 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?
- E39M5S62 3y ago
  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).

189 points by denysonique 3y ago

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

imiric 3y ago
In what way do you find NixOS to be better? I'm actually thinking of going the other way, from NixOS to Void+ZFS. I've been using NixOS on 2 machines for a few months now, so I'm relatively new to it, but I still struggle with basic things, and don't really grok the Nix language. If ZFS+ZFSBootMenu can give me easy snapshotting and rollback functionality, then I might prefer it over NixOS. Sure, Nix does many more things besides snapshots, but for my use case it's the main benefit, so I wouldn't be missing much.
- anotherhue 3y ago
  NixOS comes alive when you have ephemeral root. It's generating all of /var and /etc as it boots, from the config, and then just mounting your home directory at the end. So if I want to switch from pulse to pipewire, or some other messy change, I just edit the config, boot into it and it's like pulse never existed. If I don't like pipewire (I love pipewire) then I just choose the prior config option at boot and equally, pipewire never existed. I don't want my bootloader handling snapshots of my homedir, I can do that myself if I need (zfs auto snapshots, etc.). So with an ephemeral root, there is no other state to manage, making this kind of boot menu redundant. Think of it this way, you can carefully manage filesystem state using snapshots, or you can slap it all in the /nix store and have your system live assemble itself to spec on every boot. Like using git for your source tree instead of tar'ing up the whole thing everytime you make a scary change.
  - ahesford 3y ago
    I think you misunderstand what ZFSBootMenu does. It doesn't manage any snapshots. It refuses to do anything to any file system that isn't clearly marked as an operating system root. (There are a few well-defined criteria that must be met before ZBM will even attempt to determine if a filesystem has Linux kernels that it will allow you to boot.) Once it identifies one or more file systems that contain bootable Linux kernels, it allows the user to select a kernel from one of those file systems for booting. It also allows the user to enumerate snapshots of those bootable file systems and boot from them via ZFS cloning (with or without promotion) or a send-receive duplicate that avoids interdependencies. Yes, Nix manages a history of past system instances and NixOS modifies the bootloader to present each of these states as a bootable option. This maps loosely to the ability to elevate ZFS snapshots to boot environments in ZBM, but the functionality is not redundant. In fact, it isn't even a compatible alternative---we haven't found a good way to make ZBM boot NixOS. If you want NixOS, you're booting the NixOS way. Nix is a very interesting concept that offers several advantages. It also has drawbacks. For example, it can be inordinately complex to manage small deviations from upstream configurations that aren't represented by pre-existing options. (Ever try to add a single line to a PAM configuration file in Nix?) The Nix way of booting falls apart should you want to have multiple Linux distributions coexisting on a single pool. NixOS works best when you have complete buy-in. ZFSBootMenu doesn't care; if it can find kernels in the `/boot` directory of a ZFS filesystem, it will show you the filesystem and let you boot it.
- istjohn 3y ago
  In case you weren't aware: Timeshift > System restore tool for Linux. Creates filesystem snapshots using rsync+hardlinks, or BTRFS snapshots. Supports scheduled snapshots, multiple backup levels, and exclude filters. Snapshots can be restored while system is running or from Live CD/USB. https://github.com/linuxmint/timeshift https://github.com/linuxmint/timeshift

nisa 3y ago

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.

SushiHippie 3y ago
May I ask how you use this on the dedicated server?
- wongarsu 3y ago
  Hetzner's dedicated servers give you KVM access for stuff like tweaking your bios settings, installing an OS, or I guess using your boot menu. You have to request them via support ticket, but last time I did that I got it within 5 minutes, no questions asked. If you have your own server in a rack somewhere chances are you bought one with a similar web interface (IMPI/BMC/whatever your brand calls it) on a separate always-on NIC on the mainboard. https://docs.hetzner.com/robot/dedicated-server/maintainance/kvm-console/ https://docs.hetzner.com/robot/dedicated-server/maintainance...
  - codetrotter 3y ago
    When I installed FreeBSD on my Hetzner servers, I did so by booting the servers into the Linux based rescue mode and then I think I used dd to write the mfsBSD media onto one of the hard drives. This way I didn’t have to request KVM access for my servers. Perhaps a similar method can be used in order to install ZFSBootMenu
    - themoonisachees 3y ago
      Nice tip but if you fail your server is toast and that's an interesting support ticket.

dsp_person 3y ago

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). 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: mv initramfs-linux.img initramfs-linux.img.orig cat intel-ucode.img initramfs-linux.img.orig > initramfs-linux.img [1] https://docs.kernel.org/arch/x86/microcode.html#why-is-late-loading-dangerous https://docs.kernel.org/arch/x86/microcode.html#why-is-late-...

E39M5S62 3y ago
There shouldn't be any issues catting the real initramfs with microcode into another file. I do that, as does another ZBM developer. What do you see when you try it? I started ZBM years ago by hacking on the same grub script, then progressed to what it is now!
- dsp_person 3y ago
  When I booted normally with the concatenated image (ensuring removing the original microcode img from the grub.cfg initrd command), I booted and I confirmed the microcode loaded with (dmesg | grep microcode). Then switching to ZBM, while it did boot with the concatenated image, I didn't see microcode loaded in dmesg.

aborsy 3y ago

Does ZFSBootMenu allow for entering encryption password remotely on encrypted root?

nisa 3y ago
yes you can add an ssh server or setup network in zfsbootmenu and use keylocation=https
E39M5S62 3y ago
Yes - both Dracut and mkinitcpio allow you to embed an SSH server in the ZFSBootMenu initramfs (dropbear, or OpenSSH) and connect to it. Once you connect, you can access the main interface and unlock any datasets prior to kexec. https://docs.zfsbootmenu.org/en/v2.2.x/guides/general/remote-access.html https://docs.zfsbootmenu.org/en/v2.2.x/guides/general/remote...
- bpye 3y ago
  It's an aside - but I wish there was a way to do a kexec and keep the ZFS datasets unlocked. I don't think there's anything that stops it being technically possible, but I'm pretty sure it would require kernel mode changes...
  - E39M5S62 3y ago
    I just add the keyfile to the initramfs. It sits under an encryptionroot and is only readable by the root user, so it's largely as safe as native encryption can be.

prabir 3y ago

Been using this for arch https://github.com/prabirshrestha/simple-arch-installer https://github.com/prabirshrestha/simple-arch-installer and server https://github.com/prabirshrestha/simple-ubuntu-installer https://github.com/prabirshrestha/simple-ubuntu-installer with remote ssh unlock for zfs encryption.

londons_explore 3y ago

It seems lame that UEFI firmware needs to 'mount' a filesystem to load a bootloader. That bootloader needs to mount a filesystem to find the kernel. The kernel needs to mount the filesystem to run the system. 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. It really feels like the boot process is more complex than it needs to be, with more opportunities for failure than necessary.

jeroenhd 3y ago
There's not really a way around it unless you hardcode the bootloader rather than store it on disk. That said, there are only two steps in the modern boot process on a PC: the UEFI firmware loading a basic FAT driver and the kernel mounting the other filesystems. The UEFI bootloader can use the existing FAT driver to load the kernel and the initramfs which will use the same code to mount partitions. You can skip the UEFI bootloader and directly boot unified kernel images after putting them on the UEFI partition.
- londons_explore 3y ago
  I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. That effectively removes all config from the process - and means that any disk with a uefi executable kernel can be booted without the mystery step of "lets try to figure out where we're booting from".
  - hackmiester 3y ago
    This does work inside of rEFInd, which can load a kernel EFI blob directly, and supply it args.
  - bpye 3y ago
    > I'd quite like UEFI to be able to pass some kind of argv[0] to the direct-loaded kernel, so the kernel knows exactly which file on which partition of which disk it was loaded from. That would then become the default root filesystem. I think UEFI gives an EFI application (such as the Linux kernel) everything it would need for this already - but I guess Linux doesn't use it. The EFI application entry point includes a handle to your own image [0], and the EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL_GUID [1] protocol allows you to query the path it was loaded from. It is possible for an image to be loaded without a path, but it looks like EDK2 provides it at least [2]. [0] - https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.html#efi-image-entry-point https://uefi.org/specs/UEFI/2.10/07_Services_Boot_Services.h... [1] - https://uefi.org/specs/UEFI/2.10/09_Protocols_EFI_Loaded_Image.html#efi-loaded-image-device-path-protocol https://uefi.org/specs/UEFI/2.10/09_Protocols_EFI_Loaded_Ima... [2] - https://github.com/tianocore/edk2/blob/991515a0583f65a64b3a6fa354409c64e670a762/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1932 https://github.com/tianocore/edk2/blob/991515a0583f65a64b3a6...

deleted 3y ago

[deleted]

vermaden 3y ago

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. I will wait ...

E39M5S62 3y ago
It's okay for FreeBSD if Linux can do some things it can, and vice-versa. If you're that insecure about running FreeBSD after all this time, you'd do well to think about why that is.
- assimpleaspossi 3y ago
  Running an unencumbered FreeBSD system will never make any user insecure.
dizhn 3y ago
OpenSuse Tumbleweed has btrfs+snapper and the installer sets it up automatically. I guess they could (technically) boot other operating systems but their focus is to boot into read only snapshots of the same OS. The same setup is possible on all Linux distros but the user has to set it up.
- vermaden 3y ago
  Can BTRFS snapshots on OpenSUSE Tumbleweed (btrfs+snapper) provide same functionality as ZFS Boot Environments? Nope. Cite from System Recovery and Snapshot Management with Snapper for OpenSUSE Linux. ● Limitations A complete system rollback, restoring the complete system to the identical state as it was in when a snapshot was taken, is not possible. With ZFS Boot Environments you are bulletproof. With btrfs+snapper you are crossing fingers if it will work the way you need. Not the same thing.

contingencies 3y ago

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. 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?

E39M5S62 3y ago
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).