|
|
|
|
|
|
|
|
|
|
xen-devel
RE: [Xen-devel] Re: Daily Xen Builds
> 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
|
|
|
|
|