uvt-kvm wait command will never return on Trusty with a future guest using systemd such as Xenial

Thank you for the report.

This is correct. uvtool on Trusty waits for upstart to be ready on the guest. Xenial uses systemd, so upstart never completes there. This couldn't have been known at the time of release of Trusty!

You can work around this by asking uvtool to use a custom wait script using the --remote-wait-script option.

See remote-wait.sh in the source. Here's the difference between Trusty and Xenial:

$ diff -u uvtool-0~bzr9{2,9}/remote-wait.sh
--- uvtool-0~bzr92/remote-wait.sh 2014-04-01 13:06:54.000000000 +0100
+++ uvtool-0~bzr99/remote-wait.sh 2015-04-13 17:32:11.000000000 +0100
@@ -1,8 +1,12 @@
 #!/bin/sh
 set -e

-# Wait for runlevel 2
-while [ "$(runlevel|awk '{print $2}')" != 2 ]; do sleep $UVTOOL_WAIT_INTERVAL; done
+# Wait for runlevel 2 (upstart) or 5 (systemd)
+while :; do
+ runlevel=`runlevel|awk '{print $2}'`
+ [ "$runlevel" = 2 -o "$runlevel" = 5 ] && break
+ sleep $UVTOOL_WAIT_INTERVAL
+done

 # Wait for cloud-init's signal
 while [ ! -e /var/lib/cloud/instance/boot-finished ]; do sleep $UVTOOL_WAIT_INTERVAL; done

This could be SRU'd to Trusty perhaps (I'm not sure how it really fits in with policy, since it's not a regression; rather an attempt to work well with the future from the perspective of Trusty). Someone will need to drive any such SRU. If a volunteer is found, I'll leave it to other SRU team members make the SRU policy decision.

Hi Robie,
thanks for the hint, I will try to fix this in Trusty!

The debdiff is reversed (which a sponsor could work around) but is also based on 0~bzr92-0ubuntu1.1 which is already published.

I think you'd be better served getting help from other Ubuntu developers from a public channel, such as #ubuntu-devel. Then you won't get blocked on me in preparing an acceptable upload. I'm sorry I didn't ask you to do this before. Please get help from #ubuntu-devel rather than just from me. I encourage others to sponsor your upload when it's ready.

Hi Robie,

The 0~bzr92-0ubuntu1.1 is the latest version that I can get from Trusty repository (another one is 0~bzr92-0ubuntu1). So it's a bit confusing here, I got the package with apt-get source command, should I use something else for this specific fix in Trusty?

(And another question just out of curiosity, why we're not using bzr for the patch review?)

Anyway, thanks for taking a look on this.
I will try to bug someone else.

The best way to work on this would be to use the following commmands:

apt-get source uvtool=0~bzr92-0ubuntu1.1
cd uvtool-0\~bzr92
dch -i

This will correctly increment the changelog to 0~bzr92-0ubuntu1.2 and you can add your changelog entry there. It looks like you may have reversed your debdiff output when producing a patch for this bug. I'm going to unsubscribe ubuntu-sponsors while you continue to work on this.

Hey Sam, we still working this?

Stalled, I will check on the current status for the KVM smoke test, the behaviour seem a bit different now.

Hey Sam,

Trusty's HWE kvm smoke tests appear to have passed on amd64 but looks like it's hiccuping on a couple of other arches. I don't know how useful that information is here for this bug though. Given that Trusty is ESM, is this SRU-able still?

Hi Connor,
thanks for checking this issue.

we have changed the test to boot $RELEASE on $RELEASE (used to be Xenial on all the other releases, and therefore X on T is affected by this bug)

Base on this we can say it's no longer an issue for the test itself. It's still a issue for the tool, but I think maybe we can ignore it as it's ESM now.

For failures on other arches, it might be something else (missing templates etc.)

I will close this bug, thank you!