Re: [PATCH OSSTEST v4 00/25] add distro domU testing flight

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-04-02 at 12:21 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[Xen-devel] [PATCH OSSTEST v4 00/25] add distro domU testing flight"):
> > The failures mainly seem to be some sort of proxy issue returning old
> > data (similar to what used to happen to mg-debian-installer-update),
> 
> Maybe we can set up an explicit proxy which actually works.  I guess
> that might need negotiation with Citrix corporate IT.

I think it would, in order for the proxy to get past the intercepting
thing. I suspect the best answer we could expect would be "here is how
to use the intercepting thing directly", which is unlikely to help.

> Luckily the new colo is not affected by anything like this.

Indeed, and I was thinking that this flight would normally run there,
unless capacity concerns mean not for now.

> > On a small number I see "The installer failed to download a file from
> > the mirror." messages, which might be the cache/proxy or might be an
> > actual Debian issue.
> 
> Hrm.  I find these vague error messages exceptionally frustrating
> (debootstrap has this problem too).

If it happened in an interactive install you could get to a more
comprehensive logs, but that's not that useful for automation.

Perhaps a wishlist against d-i such that if it is preseeding and
DEBIAN_FRONTEND=text it will dump /var/log/syslog on fail? Or at least
an option to do so.

> > The -raw tests all failed due to a timeout doing:
> >         dd if=/dev/zero of=/var/lib/xen/images/debian/disk.raw bs=1M count=10000
> >         
> > I'm unclear if it timed out after 30 (as the code seems to say) or 60
> > (as the logs seem to say) but either way something obviously needs
> > adjusting. I just tried it on my local test box and it took 1m20s and
> > reported 130 MB/s. I've appended an as yet untested patch which assumed
> > 100 MB/s and calculates a timeout from that.
> 
> Do you intend to fold that patch in ?

Yes, I just left it separate on this iteration because it was new and
untested, even if somewhat obvious.

> > I could switch to using "count=1 seek=10000" to create a sparse file,
> > which should be pretty much instantaneous, but allocating the whole
> > backing file seemed like a good idea.
> 
> Right.
> 
> Thanks,
> Ian.