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

Bug #1732883 reported by Po-Hsu Lin on 2017-11-17
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ubuntu-kernel-tests
Undecided
Po-Hsu Lin
uvtool (Ubuntu)
Undecided
Unassigned
Trusty
Low
Po-Hsu Lin

Bug Description

== SRU Justification ==

[Impact]
* When running a newer guest (which uses systemd) on Trusty, the `uvt-kvm wait` command will never return as the tool is not aware of the newer runlevel 5 for systemd.

[Test Case]
Steps:
 1. Install Trusty + X-hwe kernel
 2. sudo apt-get install uvtool -y
 3. ssh-keygen -f /home/ubuntu/.ssh/id_rsa -t rsa -N ''
 4. sudo uvt-simplestreams-libvirt sync release=xenial arch=amd64
 5. sudo uvt-kvm create test-kvm release=xenial arch=amd64
 6. sudo uvt-kvm wait test-kvm --insecure

Result:
 * Step no 6. will never return. Even you can already ssh into that KVM

[Regression potential]
* This patch only adds compatibility for Trusty users, and limited to the uvt-kvm wait command on Trusty, therefore the risk for causing a regression is low.
* This patch has been tested on Trusty, with positive test result.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-4.4.0-98-generic 4.4.0-98.121~14.04.1
ProcVersionSignature: User Name 4.4.0-98.121~14.04.1-generic 4.4.90
Uname: Linux 4.4.0-98-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.25
Architecture: amd64
Date: Fri Nov 17 10:13:10 2017
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: linux-lts-xenial
UpgradeStatus: No upgrade log present (probably fresh install)

Po-Hsu Lin (cypressyew) wrote :
affects: linux-lts-xenial (Ubuntu) → uvtool (Ubuntu)
Robie Basak (racb) wrote :

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.

summary: - uvt-kvm wait command will never return on Trusty with KVM created with
- uvtool
+ uvt-kvm wait command will never return on Trusty with a future guest
+ using systemd such as Xenial
Changed in uvtool (Ubuntu):
status: New → Fix Released
Changed in uvtool (Ubuntu Trusty):
status: New → Triaged
importance: Undecided → Low
Po-Hsu Lin (cypressyew) wrote :

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

Changed in uvtool (Ubuntu Trusty):
assignee: nobody → Po-Hsu Lin (cypressyew)
Po-Hsu Lin (cypressyew) on 2017-12-06
Changed in uvtool (Ubuntu Trusty):
status: Triaged → In Progress
Po-Hsu Lin (cypressyew) on 2017-12-06
description: updated
Po-Hsu Lin (cypressyew) on 2017-12-06
description: updated
Po-Hsu Lin (cypressyew) on 2018-01-24
description: updated
Po-Hsu Lin (cypressyew) on 2018-01-24
description: updated
Po-Hsu Lin (cypressyew) wrote :
Robie Basak (racb) wrote :

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.

Po-Hsu Lin (cypressyew) wrote :

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.

Brian Murray (brian-murray) wrote :

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.

Po-Hsu Lin (cypressyew) on 2018-06-01
Changed in ubuntu-kernel-tests:
assignee: nobody → Po-Hsu Lin (cypressyew)
Sean Feole (sfeole) wrote :

Hey Sam, we still working this?

Changed in ubuntu-kernel-tests:
status: New → Incomplete
Po-Hsu Lin (cypressyew) wrote :

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

Po-Hsu Lin (cypressyew) on 2018-10-31
Changed in ubuntu-kernel-tests:
status: Incomplete → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers