4 ms·
Root on ZFS just feels too much like playing with fire to me. Fixing an unbootable ext4 filesystem seems tricky enough already. Am I just in the dark on how t
by AviationAtom 4y ago
Root on ZFS just feels too much like playing with fire to me.
Fixing an unbootable ext4 filesystem seems tricky enough already.
Am I just in the dark on how to easily repair boot issues, especially on more modern filesystems?
I feel like the OP probably had to put countless hours into working through all these issues to finally get back to a fully functioning environment.
- Gordonjcp 4y agoWhy would you bother? It'll be quicker to just blow it away and reinstall.
- AviationAtom 4y agoYou're not concerned about all your system settings, installed applications, and any other data worthy of preservation on your root disk? Or am I misunderstanding how Root on ZFS works/boots?
- Gordonjcp 4y agoNo, why would I be? In what world would you even lose all that?
- AviationAtom 4y agoWhat specifically would a reinstall cover then? Is it just a boot partition/stub (FAT?) that loads the root ZFS pool? It all seems like a drastically different architecture than I'm used to seeing on a system.
- Gordonjcp 4y agoWhy would you keep /home on the same partition? Why would you be manually adding in apps after a reinstall? You just script this shit.
- AviationAtom 4y agoI should add that, in my brief searching, to learn more about my own question, I stumbled on this. It seems much akin to the very cool rEFInd bootloader: https://docs.zfsbootmenu.org/en/latest/ https://docs.zfsbootmenu.org/en/latest/
- mastax 4y agoI use ZFSBootMenu on my servers. I was going to mention it. Love it. Only had to use it once to boot to an older snapshot, but it was so much nicer than the grub console. Do have to make sure you don't let it get too old and upgrade your zpool features that it doesn't support, but that's always true with ZFS boot.
- E39M5S62 4y ago(one of the ZBM developers here) - we strive to provide the best recovery environment possible. Between cloning/promoting previous snapshots through our interface, a full shell with ZFS userland tools, and the ability to chroot read/write into any boot environment (or read-only into a snapshot), we can help you out of quite a few common binds. There's usually no need to keep a recovery disc around!
- AviationAtom 4y agoThis is part of what I love about Hacker News so much. It seems like almost any item posted on here quickly has someone that is involved with the project commenting on the post, offering their help and insights! I'm looking forward to running ZBM through it's paces when I get some time. I actually found out about it from a Reddit comment by Jim Salter a.k.a. Mercenary Syadmin, a huge ZFS advocate.
- nubinetwork 4y agoIt's pretty easy to avoid if you keep your previous kernel in your boot directory... new kernel won't boot? Just boot the old one until you can fix the new one.
- fuzzy2 4y agoIt’s super convenient though! Snapshots, clones, compression, encryption, differential backups and whatnot. Though much of it can be had with btrfs, too, these days. Repairing many boot issues is highly trivial. Just chroot in, fix whatever is wrong (boot manager/UEFI vars/kernel/initramfs/…) and done. Pretty much like bcdboot on Windows or fiddling with the registry offline. Certainly, you need to know your stuff. But the basic Linux boot process is quite simple and easy to understand. There is no hidden magic except perhaps sort-of in the initramfs. The only hard part is sometimes finding out what is wrong: Wrong/mangled kernel command line? Bug in some initramfs hook? Or actual failing hardware? But all that is mostly not specific to whatever filesystem you use. ZFS certainly complicates things a bit in that you need a compatible live medium. But if we take a step back, you also do for LVM, LUKS, Software RAID, … Of course, if we’re talking about failure modes of the filesystem itself (corruption, hardware issues and the like), ZFS can give you a pretty bad time, because resources are not so readily available on the net.