Hi, Quoting Helmut Grohne (2023-09-23 20:18:21) > Quoting Ian Jackson (2023-09-23 12:19:27) > > To summarise that discussion: at that time the best available solution that > > worked in ci.d.n seemed to be to write an ad-hoc script to run the tests in > > qemu; three packes had done that, each separately, with complex scripts > > with many moving parts.
the three packages are probably sbuild, dropbear and cryptsetup?
> > I saw debvm, and wondered if it was suitable for this purpose. But, then I
> > looked at its debian/test/control and I see that the tests are marked as
> > flaky.[2] So maybe it isn't reliable enough :-/.
>
> The reliability of tests is ok. The reason for marking them flaky is that
> they currently test the "wrong" packages. ci.d.n sets up chroots in a
> delicate way to combine particular packages to see which combinations cause
> breakage. Then debvm just creates an unstable system and tests that. In
> effect, it currently tests unstable (inside those virtual machines) rather
> than what it is supposed to be testing.
>
> Johannes solved this problem on the mmdebstrap side and mmdebstrap's
> tests no longer are flaky in this way. Therefore this should be solvable
> on the debvm side. I just haven't gotten do figuring out the right runes
> thus far. Roughly speaking, the hosts' apt configuration, pinning and
> sources.lists should be used inside the created virtual machine.
right now the mmdebstrap autopkgtest only mimics sources and pinning of the
outside system. I had not considered that apt configuration on salsaci or debci
was set to something that influenced the tests. Is the apt configuration on
those systems set to something that is not the default and should be considered
as well?
There is really not much magic. The core of it is to pass this to your
mmdebstrap or debvm-create invocation:
--setup-hook='for f in /etc/apt/sources.list /etc/apt/sources.list.d/*
/etc/apt/preferences.d/*;
do [ -e "$f" ] && { echo; sed "s| file://| copy://|" "$f"; }
| tee "$1/$f" >&2; done'
--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount
The first will hook will make sure that the chroot receives the sources and
pinning values of the outside system. The second will do some bind-mount magic
which allows the chrooted processes to access even file:// repositories from
outside the chroot. Full script here:
https://sources.debian.org/src/sbuild/0.85.3/debian/tests/unshare-qemuwrapper/
> There is another practical problem. None of the autopkgtest nodes support
> kvm. Emulation will always use tcg. For one thing, tcg is slow. It can be so
> slow on some architectures that RCU becomes unhappy as its grace periods
> become too long. For another, tcg is buggy. It has emulation bugs even on
> release architectures that make some expected functionality fail. For
> instance, gdb reliably segfaults when run in s390x tcg emulation.
Architectures that are not amd64 or arm64 are a common source of problems. The
current sbuild autopkgtest hits another issue when running qemu on s390x:
514s ^M[ 28.399829] illegal operation: 0001 ilc:1 [#1] SMP
514s ^M[ 28.400490] Modules linked in: chacha_s390(+) libchacha virtio_pci
virtio_pci_legacy_dev virtio_pci_modern_dev virtio_blk
514s ^M[ 28.402977] CPU: 4 PID: 163 Comm: cryptomgr_test Not tainted
6.5.0-1-s390x #1 Debian 6.5.3-1
514s ^M[ 28.403150] Hardware name: QEMU 8561 QEMU (KVM/Linux)
514s ^M[ 28.403285] Krnl PSW : 0704c00180000000 0000000000000042 (0x42)
514s ^M[ 28.403964] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0
PM:0 RI:0 EA:3
[...]
514s ^M[ 28.408739] Last Breaking-Event-Address:
514s ^M[ 28.408758] [<000003ff800fb084>] chacha_crypt_generic+0x54/0xfd0
[libchacha]
514s ^M[ 28.409610] ---[ end trace 0000000000000000 ]---
https://ci.debian.net/data/autopkgtest/testing/s390x/s/sbuild/38123402/log.gz
In addition to debvm, these tests should maybe directly depend on qemu so that
they get run on new qemu uploads that trigger these kinds of regressions.
Assuming this is really a qemu problem and not something a new kernel version
introduced...
Thanks!
cheers, josch
signature.asc
Description: signature
