On Fri, 27 Mar 2026 23:04:22 +0100 Benjamin Drung <[email protected]> wrote: > Hi, > > On Tue, 2026-03-24 at 21:51 +0000, Luca Boccassi wrote: > > Source: dracut > > Severity: serious > > Justification: blocks other packages from migrating > > > > Dear Maintainer(s), > > > > The dracut autopkgtests on ppc64el are flaky, and many runs fail: > > > > https://ci.debian.net/packages/d/dracut/testing/ppc64el/ > > > > What's worse is that each run is ~7 hours, so it takes a full day just > > for a couple retries. This blocks other packages from migrating. > > > > If this is not possible to fix, please consider disabling autopkgtest > > on ppc64el, or marking the test suite as flaky. Thanks. > > I spent a lot of time to address the flakyness of the dracut tests > (races, timeouts, etc). The flakyness should be fixed in dracut 110-7 > (there is one more timeout fix for test 41 in 110-8). > > There are three test failures of 110-7: > > 1) 72-nbd: kernel BUG at arch/powerpc/include/asm/interrupt.h:355 > 2) 70-iscsi: I/O error, dev sdb, sector 69122 op 0x0:(READ) > 3) 71-iscsi-multi: timed out (last log line: "Run /init as init process") > > So failure 1 and 2 look like kernel related. Failure 3 does not look > like dracut being the culprit.
We discussed this offline, so I'm following up here to summarise that conversation from my point of view. I suggested that some of the flakiness here may be the fault of QEMU rather than anything else. Case 1 looks like an "impossible" assertion failure and the other 2 like flaky (emulated) storage devices. I thought it would make sense to run a reduced test suite on architectures where we don't expect the CI runners to have access to KVM. This would mitigate the slowness and (somewhat) the bugginess of software-only QEMU. Since we do have KVM on x86 (if I understood correctly) the full test suite would still get run there. Ben. -- Ben Hutchings Tomorrow will be cancelled due to lack of interest.
signature.asc
Description: This is a digitally signed message part
