Re: [Xen-devel] [linux-linus test] 12620: regressions - trouble: blocked/broken/fail/pass [and 1 more messages]

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Konrad Rzeszutek Wilk writes ("Re: [Xen-devel] [linux-linus test] 12620: 
regressions - trouble: blocked/broken/fail/pass"):
> On Mon, Apr 09, 2012 at 07:18:24PM +0100, xen.org wrote:
> > flight 12620 linux-linus real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/12620/
> > version targeted for testing:
> .. snip..
> >  linux                0034102808e0dbbf3a2394b82b1bb40b5778de9e
> 
> Hm, that version should have worked.

Thanks for looking.

> > jobs:
> >  build-amd64                                                  pass    
> >  build-i386                                                   broken  
> 
> Ah, so b/c of that the other things broke. I am not actually
> sure what is broken except that the initrd looks to have not been
> pushed properly?

These failures:

> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-i386-pvops              2 host-install(2)      broken REGR. vs. 12557
>  build-i386                    2 host-install(2)      broken REGR. vs. 12557
>  test-amd64-amd64-xl-win       3 host-install(3)      broken REGR. vs. 12557
>  test-amd64-i386-xend-winxpsp3 3 host-install(3) broken in 12609 REGR. vs. 
> 12557

are because one my my test boxes forgot how to boot from its network
card and reverted to booting from its hard disk.  It seems that
something I am doing to my machines (perhaps the repeated power
cycling) makes this happen occasionally - the machine forgets its boot
order.  I have "fixed" this machine.

(I haven't bothered trying to get this fixed by the suppliers because
it happens to each affected machine only once in several months.)

>  test-amd64-i386-xl          7 debian-install   fail in 12609 REGR. vs. 12557

This is a different failure.  It appears to be an intermittent
problem.

At the time only dom0 was running.  The step that failed was doing a
debootstrap of a Debian guest, which is heavy on disk and network IO.
The failure was that it took more than 2000 seconds.  This operation
does depend on services from the Internet, notably our local debian
cacheing proxy and also security.debian.org.  It's most likely that
this was a transient problem with security.debian.org although I don't
see any direct evidence for that theory.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel