Hacker News new | ask | show | jobs
by sieve 701 days ago
ZFS Snapshots + Sanoid and Syncoid to manage and trigger them is what people should be doing. Unfortunately, booting from ZFS volumes seems to be some form of black art unless things have changed over the last couple of years.

The license conflict and OpenZFS always having to chase kernel releases often resulting in delayed releases for new kernels means I cannot confidently use them with rolling release distros on the boot drive. If I muck something up, the data drives will be offline for a few minutes till I fix the problem. Doing the same with the boot drive is pain I can live without.
1 comments
rabf 700 days ago
Best option to date: https://github.com/zbm-dev/zfsbootmenu

A shame most distro's installers don't support it natively, but an encrypted rootfs on ZFS is great once you get it setup.

link
sieve 700 days ago
Yeah.

I am somewhat wary of trying this, mucking something up and wasting a lot of time wrestling with it. Will probably play around with it in a vm and use it during the next ssd upgrade.

Would have been so much better if the distros showed more interest in ZFS

link
aeadio 700 days ago
In principle there's no reason you can't install this next to GRUB in case you're wary. If you're not using ZFS native encryption, and make sure not to enable some newer zpool features, GRUB booting should work for ZFS-on-root.

That said, I've been using the tool for a while now and it's been really rock solid. And once you have it installed and working, you don't really have to touch it again, until some hypothetical time when a new backward-incompatible zpool feature gets added that you want to use, and you need a newer ZFSBootMenu build to support it.

Because it's just an upstream Linux kernel with the OpenZFS kmod, and a small dracut module to import the pool and display a TUI menu, it's mechanically very simple, and relying on core ZFS support in the Linux kernel module and userspace that's already pretty battle tested.

After seeing people in IRC try to diagnose recent GRUB issues with very vanilla setups (like ext4 on LVM), I'm becoming more and more convinced that the general approach used by ZFSBootMenu is the way to go for modern EFI booting. Why maintain a completely separate implementation of all the filesystems, volume managers, disk encryption technologies, when a high quality reference implementation already exists in the kernel? The kernel knows how to boot itself, unlock and mount pretty much any combination of filesystem and volume manager, and then kexec the kernel/initrd inside.

The upsides to ZFSBootMenu, OTOH,

    * Supports all ZFS features from the most recent OpenZFS versions, since it uses the OpenZFS kmod 
    * Select boot environment (and change the default boot environment) right from the boot loader menu
    * Select specific kernels within each boot environment (and change the default kernel)  
    * Edit kernel command line temporarily  
    * Roll back boot environments to a previous snapshot  
    * Rewind to a pool checkpoint  
    * Create, destroy, promote and orphan boot environments  
    * Diff boot environments to some previous snapshot to see all file changes
    * View pool health / status  
    * Jump into a chroot of a boot environment  
    * Get a recovery shell with a full suite of tools available including zfs and zpool, in addition to many helper scripts for managing your pool/datasets and getting things back into a working state before either relaunching the boot menu, or just directly booting into the selected dataset/kernel/initrd pair.
    * Even supports user mode SecureBoot signing -- you just need to pass the embedded dracut config the right parameters to produce a unified image, and sign it with your key of choice. No need to mess around with shim and separate kernel signing.
link