5 ms·
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
by 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 agoI 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.