Systemd ordering cycle on new 26.04 install - preventing zfs mounts at boot

[kpatz]

Ubuntu Support Template

Ubuntu Version: 26.04 LTS

Desktop Environment (if applicable): GNOME

Problem Description:

Installed 26.04 desktop on machine previously running 22.04 (clean install on a spare partition), installed and setup all the packages I use (samba, zfs, apache2 etc.) and got most of it working. I’m having a multitude of issues, but am starting with this one first.

The problem I’m having right now is when I boot, my zfs mounts don’t mount until I log in and do them manually with sudo zfs mount -a.

Looking at journalctl -b I see an ordering cycle being broken by systemd and it’s not running zfs-mount.service as a result.

Here’s a breakdown of the cycle (I added line breaks for readability):

 snapd.mounts.target: Found ordering cycle:  
 
 snap-prompting\x2dclient-204.mount/start after 
 snapd.mounts-pre.target/start after 
 zfs-mount.service/start after 
 zfs-load-key.service/start after 
 basic.target/start after 
 sockets.target/start after 
 uuidd.socket/start after 
 sysinit.target/start after 
 snapd.apparmor.service/start after 
 apparmor.service/start after 
 local-fs.target/start after 
 snapd.mounts.target/start - after 
 snap-prompting\x2dclient-204.mount
 

As you can see it’s cycling back to snap-prompting\x2dclient-204.mount.

The only change I made from the base install (relevant to this) was adding zfs-load-key@.service to load the encryption key for my zfs pool.

[Unit]
Description=Load ZFS keys
DefaultDependencies=no
Before=zfs-mount.service
After=zfs-import.target
Requires=zfs-import.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/zfs load-key %I

[Install]
WantedBy=zfs-mount.service

I had 22.04 set up the same way and it worked without a problem, but I don’t think snap-prompting existed in that version.

I’m guessing it has to do with snapd.mounts.target or one of its related items.

Suggestions? Thanks.

[peterwhite23]

@kpatz

The only change I made from the base install (relevant to this) was adding zfs-load-key@.service to load the encryption key for my zfs pool.

[Unit]
Description=Load ZFS keys
DefaultDependencies=no
Before=zfs-mount.service
After=zfs-import.target
Requires=zfs-import.target

DefaultDependencies=no can be tricky. Can you disable that service and check if that breaks the ordering cycle?

[kpatz]

I think I found the issue. Turns out I had installed/enabled the zfs-load-key@.service with:

sudo systemctl enable zfs-load-key.service

which caused the message “

zfs-load-key.service is not a native service, redirecting to systemd-sysv-install.

The result being the dependencies/load order was all messed up (discovered by examining the output of systemctl list-dependencies) causing my zfs-load-key to be in multiple places and not just in zfs.target).

After disabling that and reinstalling it with

sudo systemctl enable zfs-load-key@pool-data.service

Adding the parameter of the dataset to have the key loaded to fixed the problem. I’ve rebooted a few times now and the zfs is mounting and I’m not getting ordering cycle messages in the logs anymore.

Got a few other issues to figure out next, but those will be new topics as needed. Thanks.