Comment 9 for bug 2039441

Revision history for this message
Brett Holman (holmanb) wrote :

This condition was possible prior to the change in cloud-init. Cloud-init's ordering change just revealed this unhandled condition in uvtool.

From systemd-user-sessions.service(8):

> After basic system initialization is complete, it removes /run/nologin, thus permitting logins.

From uvt-kvm(1):

> Wait for a VM to become ready....

Given the purpose and scope of uvtool's `uvt-kvm wait` and systemd-user-sessions.service, this looks like a condition that uvtool should really be able to handle; when logins are not permitted the VM is not "ready".

Cloud-init made the change in b3c9b6a79c to fix a real bug caused by implicit systemd ordering assumptions proved invalid (observed on odd architectures and virtualized instruction sets).

Ultimately, this isn't cloud-init's responsibility, and uvtool should likewise be fixed to handle this condition.

That said, due to LP: #2039505, this change will temporarily be reverted until snapd is no longer an ordering dependency, since #2039505 is a serious regression.

Advise this delay be used to fix uvtool such that when cloud-init re-implements this change uvtool works seamlessly.