Comment 8 for bug 1721414

This is not in fact fixed. The current guess at the problem is that although subiquity.service is ordered after snap.subiquity.started.service, the latter is not known to systemd early enough and so it starts subiquity.serivce anyway.

My next idea for a hack is to put "ExecStartPre=/usr/bin/snap version" or something like that in subquity.service on the theory that thanks to the magic of socket activation this will block until snapd is actually serving api requests, and that it doesn't serve api requests until seeding is done and the mounts are set up. I haven't actually checked this last bit though.

Perhaps we should engage the snapd team (i.e. post in the forum) about this. It's pretty thorny.