RE: [Xen-devel] Re: Daily Xen Builds

["Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>]

> IP> The changes to xm-test you posted on Friday seem to have 
> broken the 
> IP> initrd such that the guest can't mount /proc, which seems 
> to account 
> IP> for the failures.
> 
> Actually, the problem is not from my Friday changes.  I 
> pulled the initrd's from David's machines.  The machine with 
> only 8 failures had a correct initrd, while the others had an 
> older version that was made before the init script was made 
> to be +x.  Not sure why.  He is going to blow away all of his 
> existing trees today and see if that fixes the problem.
> 
> Having the rcS file not +x meant that /proc wasn't being 
> mounted, which led to many failures.  We cleared this up 
> shortly after the import since a lot of file permissions were lost.

OK, so I believe we're agreed it's "case closed" as regards an actual
regression.

The 8 outstanding failures are on the todo list, but the prime focus in
on #411, which hasn't been seen by many people, but is very serious. It
would be very useful to know if anyone has seen this who is *not* using
python 2.3.5.
 
> IP> The mini XenRT run used for the staging tree still uses 
> xm-test v0.3 
> IP> as latter versions are too slow (though I know you're working on 
> IP> this), and we're not seeing these failures, hence 
> changesets are still getting out.
> 
> Current versions run in about half the time of 0.3 on my machine.
> Also, the current version of the runtest script has a "quick" 
> mode that only runs a subset of the whole suite, which 
> exercises some key areas.  I definitely think that the mini 
> XenRT should be at least running the latest quick tests.

Yep, we fully intend to. 

Thanks,
Ian

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