[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |