Comment 7 for bug 1952084

FYI this also breaks "systemctl restart snapd.seeded.service" in the same environment, and since this is unconditionally called from /var/lib/dpkg/info/snapd.postinst any snapd update on such a system will get stuck forever.

The former workaround of stopping the snapd.seeded unit thereby is not a valid mitigation anymore as soon as there is a snapd update.

This also affects snapd.failure.service which is stuck on restart in this environment as well.