Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ZFSBootMenu

docs.zfsbootmenu.org

Post reply on HN
Print view View original

31–40 of 56 posts

Re: ZFSBootMenu

#31

Post by anotherhue »

imiric wrote: post #27
anotherhue wrote: post #2

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.

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 th…

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.

Re: ZFSBootMenu

#32

Post by [deleted] »

londons_explore wrote: post #13

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 misco…

[deleted]

Re: ZFSBootMenu

#33

Post by istjohn »

imiric wrote: post #27
anotherhue wrote: post #2

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.

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 th…

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

Re: ZFSBootMenu

#34

Post by ahesford »

anotherhue wrote: post #31
imiric wrote: post #27

Earlier quoted context omitted.

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 th…

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 equal…

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.

Re: ZFSBootMenu

#35

Post by E39M5S62 »

vermaden wrote: post #18

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

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.

Re: ZFSBootMenu

#36

Post by dizhn »

vermaden wrote: post #18

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

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.

Re: ZFSBootMenu

#37

Post by cperciva »

londons_explore wrote: post #13

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 misco…

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

Not on FreeBSD. Our bootloader reuses kernel code (because, you know, developing the entire operating system together makes this possible).

Re: ZFSBootMenu

#38

Post by Nextgrid »

londons_explore wrote: post #13

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 misco…

The firmware can execute UEFI binaries from any filesystem it can read. The spec mandates FAT32 as a supported filesystem, but nothing prevents additional filesystems from being supported - Apple's firmware for example understands APFS (and previously, HFS+).

The Linux kernel can act as an EFI binary/application using a mechanism/feature called EFISTUB and thus can be loaded directly. The concept of a "bootloader" in UEFI-based Linux system is mostly vestigial (to enable feature-parity with non-UEFI systems or work around broken firmware). On a non-defective UEFI firmware, a bootloader is unnecessary, the UEFI firmware can load your kernel and initrd directly from the EFI system partition.

Ideally you'd want your UEFI to be able to read and understand your main filesystem (ZFS in this case) which means you no longer need a separate EFI system partition to store your kernel/initrd (and can enjoy the redundancy and features provided by your filesystem of choice). UEFI is actually extensible so you can have third-party drivers (you'd need to store those drivers somewhere, but a USB stick/memory card would do, or you could technically embed it in your firmware)?

The problem when it comes to ZFS specifically is that there is no UEFI-based driver with feature parity to the main ZfsOnLinux project. GRUB has a primitive implementation (extracted as stand-alone EFI drivers here: https://efi.akeo.ie) but it lacks support for many features, effectively forcing you to have a separate boot-time ZFS partition with all unsupported features disabled (if you're going to use a separate partition, why not just use FAT32 which is natively supported).

Re: ZFSBootMenu

#39

Post by tehlike »

nisa wrote: post #3

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

how do you use this with hetzner-cloud? Do you use it as a vm or as part of, say, k8s?

Re: ZFSBootMenu

#40

Post by themoonisachees »

codetrotter wrote: post #14
wongarsu wrote: post #11

Earlier quoted context omitted.

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 al…

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

Nice tip but if you fail your server is toast and that's an interesting support ticket.
Post reply on HN