Re: [Xen-devel] [xen-unstable test] 7753: regressions - FAIL

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 7753: regressions - 
FAIL"):
> Is there any indication where to look for the cause of a particular
> failure in the various logs? As it's (with one exception) all the
> same step that's failing, I tried to spot what failed but wasn't
> able to (and that happened to me several times in the past) - no
> sign of a crash or timeout or anything afaics.

In general the place to start is the step log, like this:

Start with:
  http://www.chiark.greenend.org.uk/~xensrcts/logs/7753/ 
now observe which test is failing badly, and click on its column
heading:
  
http://www.chiark.greenend.org.uk/~xensrcts/logs/7753/test-amd64-amd64-xl/info.html

There is a list of steps there.  If you click on "fail" you'll see the
test harness transcript:
  
http://www.chiark.greenend.org.uk/~xensrcts/logs/7753/test-amd64-amd64-xl/16.ts-guest-start.log

In this case the relevant part is:

  2011-06-28 22:45:04 Z executing ssh ... root@xxxxxxxxxxxxx lvdisplay --colon 
/dev/woodlouse.cam.xci-test.com/debian.guest.osstest-disk
  2011-06-28 22:45:05 Z executing ssh ... root@xxxxxxxxxxxxx umount 
/dev/woodlouse.cam.xci-test.com/debian.guest.osstest-disk
  umount: /dev/woodlouse.cam.xci-test.com/debian.guest.osstest-disk: not mounted
  2011-06-28 22:45:05 Z command nonzero waitstatus 256: ssh -o 
StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 -o PasswordAuthentication=no -o 
ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_7753.test-amd64-amd64-xl 
root@xxxxxxxxxxxxx umount 
/dev/woodlouse.cam.xci-test.com/debian.guest.osstest-disk

Unfortunately this is not as clear as it could be; I have committed a
change to make this clearer.  What is happening is that the test
harness does "lvdisplay --colon" to see whether the LVM volume to be
used for the guest is in use.

If it is in use, the test harness tries to umount it on the theory
that something in dom0 may have left it mounted.  (This can happen if
one is doing stuff manually in between, although not in production.)
In the event that fails because the volume is not in fact mounted in
dom0.

The root cause is that something is leaving the LVM volume in use.  Ie
this is a toolstack bug; there were a lot of toolstack patches
committed recently.

My bisector had been confused by me changing the git url for the
kernel tree; I have unwedged that and hopefully it will produce an
answer soon.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel