On Wed, Apr 27, 2016 at 10:59 AM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: > On Wed, 2016-04-27 at 11:32 -0500, Bruno Wolff III wrote: >> On Wed, Apr 27, 2016 at 09:13:36 -0700, >> Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: >> > >> > So please expect the RC to arrive in the next several hours, if all >> > goes well, and be ready to test :) It won't be super different from the >> > current nightly, but we'll at least need to do sanity testing and make >> > sure we cover the few Beta tests which have not been run recently. >> >> How are the semi-random livemedia compose failures >> (https://bugzilla.redhat.com/show_bug.cgi?id=1315541) going to be handled? > > We do the compose and cross our fingers and hope really hard that none > of the release blocking media fail. If they do, we do another compose. > > :( > > I don't think there is any better option, with new Pungi we can't > really retry a single deliverable from the compose and then 'ninja' it > in, because it'd conflict with all the metadata and the compose logs > and such. > > We really do need a fix for that bug :/ Difficult when there's no local reproducer and the compose logs lack sufficient granularity: no kernel messages, and no user space messages for the failing e2fsck. Every compose has umount failures of one sort or another which itself is not OK, it's just that usually there's no consequence. I don't know enough about how composes work, but if the e2fsck runs in an environment distinct from the install environment (like a VM) then e2fsck doesn't know that the file system is still mounted in the VM; nor that qemu cache unsafe means guest commits aren't guaranteed to be committed on the host. So it could be either a delayed or failed mount, or delayed host side commits from qemu's disk cache. Or something else entirely. Like I mention in the bug, throw spaghetti at a wall and change the cache setting from unsafe to none and see if that fixes it. Locally I use cache=unsafe all the time but it does result in non-determinstic commit delays on the host, if something bad happens on the host this guarantees data loss, and while the host isn't dying in this bug, e2fsck might just be running too soon on the host to use this cache option. -- Chris Murphy -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@xxxxxxxxxxxxxxxxxxxxxxx
