ZOL version 0.6.5.8 - WARNING

[Bronek]

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 openzfs/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 openzfs/zfs#6822 )

[demizer]

Awesome. Thanks for the heads up!

[kerberizer]

Indeed. I remember back then having to do something like this to be able to boot...

systemctl preset \
    $(tail -n +2 /usr/lib/systemd/system-preset/50-zfs.preset | cut -d ' ' -f 2)

It was also a good opportunity to learn about systemd preset files.

[demizer]

@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:

# ZFS is enabled by default
enable zfs-import-cache.service
disable zfs-import-scan.service
enable zfs-mount.service
enable zfs-share.service
enable zfs-zed.service
enable zfs.target

Arch overrides this behavior by disabling all units by default, but since the zfs kernel modules are loaded in the zfs-import-* unit files, this make it is necessary to manually load the modules after reboot to enable the filesystem commands. (Which is what the command kerberizer posted does).

# zfs list
The ZFS modules are not loaded.
Try running '/sbin/modprobe zfs' as root to load them.

This is not a ideal and I think we should auto load the zfs modules at boot with /etc/modules-load.d/zfs.conf. This will allow the user to use the zfs filesystem. The user should then enable the appropriate systemd units. ZOL ships with a decent systemd preset, 50-zfs.preset, and it can be enabled simply with:

# cd /usr/lib/systemd && cp --parents system-preset/50-zfs.preset /etc/systemd/

[kerberizer]

Arch overrides this behavior by disabling all units by default (...)

I think the Wiki might not be very precise here. According to systemd.preset(5)...

All preset files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same unit name, the entry in the file with the lexicographically earliest name will be applied. (...)

Example 1. Default off example /usr/lib/systemd/system-preset/99-default.preset:

disable *

This disables all units. Due to the filename prefix "99-", it will be read last and hence can easily be overridden by spin or administrator preset policy or suchlike.

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 systemctl preset <service> or systemctl preset-all is run. So, the users must definitely run that command for the relevant services to get enabled (or disabled; BTW, the preset{,-all} commands also accept --preset-mode= parameter to filter only the enable or disable directives from the preset).

I didn't want to use preset-all because I was lazy to check if I hadn't overridden any other presets in the past (which would then be reverted to default), and hence parsed the ZFS preset file itself, so that systemctl preset would work only on the ZFS-related services. There's probably a more elegant way to do this, but unfortunately I'm not quite sure what it could be.

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?

[demizer]

In fact, I'm pretty sure that the presets don't matter at all until systemctl preset or systemctl preset-all is run.

Right, so I tested this an a test vm and you are correct.

[root@test ~]# cat /etc/systemd/system-preset/50-zfs.preset 
# ZFS is enabled by default
enable zfs-import-cache.service
disable zfs-import-scan.service
enable zfs-mount.service
enable zfs-share.service
enable zfs-zed.service
enable zfs.target
[root@test ~]# systemctl list-unit-files | grep zfs
zfs-import-cache.service                   disabled 
zfs-import-scan.service                    disabled 
zfs-mount.service                          disabled 
zfs-share.service                          disabled 
zfs-zed.service                            disabled 
zfs.target                                 disabled 

Well that sucks. I guess we can't use 50-zfs.preset without using a weird command.

[kerberizer]

Yes, unfortunately even this document isn't much helpful. It says that systemctl preset is supposed to be included in the post-install hooks, but the problem is that the command accepts only unit names, not preset files, and doesn't even support patterns (e.g. zfs*) like e.g. list-units.

Unless I'm missing something, this essentially leaves the packager with the choice of running post-install either systemctl preset-all -- which is a bad idea, because it would also reset any customisations the user might've made to their units from other installed packages -- or systemctl preset for each of the units in the package, which, on its own, isn't too different from directly enabling/disabling them.

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.