Comment 5 for bug 1875577

This is a tricky one because all of the dependencies make sense in isolation. Even if we remove the dependency added by that upstream OpenZFS commit, given that modern systems use zfs-mount-generator, systemd-random-seed.service is going to Require= and After= var-lib.mount because of its RequiresMountsFor=/var/lib/systemd/random-seed. The generated var-lib.mount will be After=zfs-import.target because you can't mount a filesystem without importing the pool. And zfs-import.target is After= the two zfs-import-* services. Those are after cryptsetup.target, as you might be running your pool on top of LUKS.

Mostly side note: it does seem weird and unnecessary that zfs-load-module.service has After=cryptsetup.target. We should probably remove that. That is coming from debian/patches/2100-zfs-load-module.patch (which is what provides zfs-load-module.service in its entirety).

One idea here would be to eliminate the After=cryptsetup.target from zfs-import-{cache,scan}.service and require that someone add them via a drop-in if they are running on LUKS. However, in that case, they'll run into the same problem anyway. So that's not really a fix.

Another option might be to remove the zfs-mount.service Before=systemd-random-seed.service and effectively require the use of the mount generator for Root-on-ZFS setups. That is what the Ubuntu installer does and what the Root-on-ZFS HOWTO will use for 20.04 anyway. (I'm working on it actively right now.) Then, modify zfs-mount-generator to NOT After=zfs-import.target (and likewise for Wants=) if the relevant pool is already imported (and likewise for the zfs-load-key- services). Since the rpool will already be imported by the time zfs-mount-generator runs, that would be omitted.

I've attached an *untested* patch to that effect. I hope to test this yet tonight as I test more Root-on-ZFS scenarios, but no promises.