I’m currently running a Debian Bookworm distribution (MX Linux) and am considering the future and which operating systems could support OpenZFS and the ZFS Boot Menu. The clear choice would be to stick with Debian, but I’m interested in exploring other options.
Ubuntu offers built-in support for encrypted ZFS volumes, which I believe is crucial for a laptop. However, I’ve come across information suggesting that Ubuntu’s customizations and setup of OpenZFS are suboptimal.
Given the desire to upgrade the OS over time without needing to carry out a full reinstall with each major release, what are people in this community using (for single laptop single SSD), taking these factors into account?
Jim: If you read this, you can blame 2.5 admins for this question. It sounds like you guys have this running without a hitch on your laptops. Installing from scratch seems like a doable thing, MIGRATING there from a current installation running ext4 seems like a tough hill to climb. Thoughts?
Most of the “suboptimal” stuff in Canonical’s ZFS packaging revolves around Canonical’s own ZFS-on-root system, zsys, which never really got first-class treatment (read: actually finishing it). If you’re using ZFSBootMenu, you won’t get exposed to any of that, so it’s not a big issue.
I will note that Canonical has also been guilty of not coordinating as closely as it could with OpenZFS upstream, which has led at least once to them pushing out a build based on an already-obsolete upstream version with a critical bug that users really shouldn’t have been exposed to at all. But honestly, I’m not gonna pillory them on that; these things happen every now and then, and I’m not going to scream at Canonical any harder for pushing out a package based on a not-great version number than I am screaming at the OpenZFS devs for missing some issues in a particular version number and needing to correct them hastily in the next.
I migrated a working Fedora 40 (ext4) laptop to a fresh encrypted ZFSBootMenu just following their guide with three minor changes:
When it came to installing the system, instead of rsync from the live-base I mounted the old ext4 partions for / and /home and rsync’ed from those into the ZFS datasets
I used systemd-boot instead of either the direct or rEFInd options but that is only because the laptop I was using (a system76 with coreboot) doesn’t like options outside of systemd-boot. Which can be done following these steps with minor adjustments for your distro of choice
With Fedora specifically I had manually copy the kernel to /boot after dracut and rename it to match it’s version i.e. /boot/vmlinuz-6.8.9-300.fc40.x86_64
So may sound like a lot, but it’s actually super painless and upgrades have been a non-issue thus far (I’ve been using ZFS on CentOS machines for a very long time and only had a small handful of upgrade issues over the years).
Thank you for sharing that experience! I’ve been getting a bit curious about the idea of live-migration of existing installations recently, nice to hear you got one working without too much hassle.
Hi, I did try to follow the ZFSBootMenu installation tutorial for Ubuntu Jammy, but with the “noble” release (here - Jammy (22.04) UEFI — ZFSBootMenu 2.3.0 documentation).
Installation works but cant get the desktop environment to work?? Any ideas what Im doing wrong here?
Changed all Jammy to noble of course…
Thanks, but I must have messed up something else…
During installation I noticed that I couldn’t access the ubuntu-archive-server and when trying to fix the failure in name resolution, I couldn’t edit my “resolve.conf”. Will set up a separate thread here next time Ill dig in to this. Thanks again!
I’ve been doing a couple of ubuntu 24.04 installs with zfsbootmenu recently. For a desktop, I had to apt install ubuntu-desktop-minimalbefore I did the exit of the chroot and the reboot. And then everything came up fine.
For a server box, I had to configure the network using netplan, otherwise the ethernet did not come up - see another recent post i made about that. I also did apt install ubuntu-server-minimal before exiting the chroot.
It essentially boils down to “if you actively PREFER zfs-dkms, Debian gets in its way much less than Ubuntu does.”
The flaw with zfs-dkms is DKMS itself. The feature is that zfs-dkms is direct from the openzfs team, not filtered through Canonical’s maintainers, who have occasionally frustrated people with their release schedule (in one case, they released an upstream version with a pretty obnoxious bug, which the openzfs team fixed with a new minor release almost immediately, but Canonical neither packaged the new minor release, nor backported the fix from upstream into the version they HAD released).