Comment 3 for bug 1721414

journalctl:
Oct 05 06:15:43 ubuntu-server systemd[1284]: subiquity.service: Failed at step EXEC spawning /snap/bin/subiquity.subiquity-loadkeys: No such file or directory

So this looks to be some manner of race condition. The file is of course there when I finally get a shell.

I see the job declares 'Requires=snapd.service', but doesn't say anything about /ordering/ (i.e. there is no snapd unit listed in 'After').

There is a systemd unit for snap-subiquity-98.mount; unfortunately there is no unversioned unit nor an unversioned alias, so we can't depend on that.

This VM is set up using virt-manager, using some semblance of 'defaults' from zesty. Attached is the libvirt xml for this VM.

I do see snapd using 100% CPU at the time I log in; so that probably contributes to the race. I don't know what it's doing with the CPU - key generation?