Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
ZOL version 0.6.5.8 - WARNING #72
When upgrading to this version, users should be warned (as clearly as possible) to manually enable systemd services zfs-mount zfs-import-cache zfs-share and zfs-zed (which used to be named zed) . Otherwise ZFS filesystems which used to mount automatically before upgrade, will not mount on boot after upgrade. This is because of change in .service files zfsonlinux/zfs@e75507c in version 0.6.5.8
PS added Dec 2017. Users also need to enable both targets zfs.target and zfs-import.target (more details in zfsonlinux/zfs#6822 )
referenced this issue
Sep 11, 2016
@kerberizer Thanks for the tip.
For those following along at home, ZOL 0.6.5.8 ships with refactored systemd service files. Upstream uses a systemd preset file to enable zfs by default:
Arch overrides this behavior by disabling all units by default, but since the zfs kernel modules are loaded in the
This is not a ideal and I think we should auto load the zfs modules at boot with
I think the Wiki might not be very precise here. According to systemd.preset(5)...
This is exactly what Arch does, so if the manpage is correct, the Arch default should not override the ZFS preset file, since the latter comes lexicographically first. For the same reason, copying the ZFS preset to /etc shouldn't really be necessary, because the sorting is done "regardless of which of the directories [the presets] reside in", and thus it shouldn't matter if it's in /usr/lib or /etc.
In fact, I'm pretty sure that the presets don't matter at all until
I didn't want to use
Concerning the ZFS kernel modules, this sounds like a good idea. It's necessary for those who don't use ZFS as a root filesystem, right?
Right, so I tested this an a test vm and you are correct.
Well that sucks. I guess we can't use
Yes, unfortunately even this document isn't much helpful. It says that
Unless I'm missing something, this essentially leaves the packager with the choice of running post-install either
Of course, the preset files still benefit the user, who can return to a sane default if they fiddle too much with their units. And parsing the preset, while indeed weird, has the benefit of transparently following the upstream changes when compared to, say, hard-coded list of units to enable/disable post-install.
BTW, the best overall approach might be what you've already done in 30343bf: warn the user about the need to set up their units correctly and inform them where more information can be found. Probably we should add this information to the Wiki anyway, once we settle on a solution.