Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
On 2022-01-12 10:58, Christian Kastner wrote: > On 2022-01-12 20:14, Christian Kastner wrote: > > Addendum: I'm now occasionally also seeing this with arm64 when using > > sbuild with --chroot-mode=autopkgtest. I'd say it's 50/50 between > > success and failure. > > Yet another data point: by reducing the CPU count to 1, it seems that > the success rate climbs to 100% on arm64. I also encountered this with an arm64 qemu image, and the count of CPUs seems indeed to be the key difference between success and failure. On my system, the following works fine: $ autopkgtest -- qemu --cpus=1 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img Any value of --cpus greater than 1 fails consistently as follows. $ autopkgtest -- qemu --cpus=2 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img autopkgtest [16:53:30]: starting date: 2022-10-13 autopkgtest [16:53:30]: version 5.26 autopkgtest [16:53:30]: host ariel; command line: /usr/bin/autopkgtest -- qemu --cpus=2 --qemu-architecture=aarch64 /var/tmp/autopkgtest-unstable-arm64.img qemu-system-aarch64: -drive if=pflash,format=raw,unit=0,read-only,file=/usr/share/AAVMF/AAVMF_CODE.fd: warning: short-form boolean option 'read-only' deprecated Please use read-only=on instead qemu-system-aarch64: terminating on signal 15 from pid 86611 (/usr/bin/python3) : failure: The VM does not start a root shell on ttyS1 or hvc1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0 autopkgtest [16:54:04]: ERROR: testbed failure: unexpected eof from the testbed
Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
On 2022-01-02 16:21, Christian Kastner wrote: > It looks as if one of the necessary consoles is not set up properly on > armhf (it worked fine for me on arm64): Addendum: I'm now occasionally also seeing this with arm64 when using sbuild with --chroot-mode=autopkgtest. I'd say it's 50/50 between success and failure. > | host login: autopkgtest-virt-qemu: DBG: expect: found "'login prompt on > serial console'" > | autopkgtest-virt-qemu: DBG: expect: b'ok' > | autopkgtest-virt-qemu: DBG: setup_shell(): no default shell on hvc1 or > ttyS1 > | qemu-system-arm: terminating on signal 15 from pid 1316826 > (/usr/bin/python3) > | autopkgtest-virt-qemu: DBG: cleanup... > | : failure: The VM does not start a root shell on ttyS1 or > hvc1 already. The only other supported login mechanism is through --user and > --password on the guest ttyS0 With just autopkgtest, so far it's been 100% success with arm64 and 100% failure with armhf. I have no idea why success or failure isn't deterministic with sbuild+autopkgtest; the invocation is always the same. The failure seems to happen in check_root_shell() of /usr/bin/autopkgtest-virt-qemu. There's a 1s timeout in there, I increased it to 10s but that didn't change anything. This is what I see with a successful execution: > autopkgtest-virt-qemu: DBG: expect: b' login: ' > autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'" > autopkgtest-virt-qemu: DBG: expect: b'ok' > autopkgtest-virt-qemu: DBG: expect: found "b'ok'" > autopkgtest-virt-qemu: DBG: setup_shell(): there already is a shell on hvc1 This is what I see when execution fails: > autopkgtest-virt-qemu: DBG: expect: b' login: ' > autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'" > autopkgtest-virt-qemu: DBG: expect: b'ok' > autopkgtest-virt-qemu: DBG: setup_shell(): no default shell on hvc1 or ttyS1 > qemu-system-aarch64: terminating on signal 15 from pid 2939437 > (/usr/bin/python3) > autopkgtest-virt-qemu: DBG: cleanup... > : failure: The VM does not start a root shell on ttyS1 or hvc1 > already. The only other supported login mechanism is through --user and > --password on the guest ttyS0 > Undefined return value after 'open' This is how I invoke sbuild with autopkgtest chroot mode: $ sbuild --arch arm64 --dist unstable \ --bd-uninstallable-explainer apt \ --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu \ --autopkgtest-virt-server-opt --overlay-dir=/tmp \ --autopkgtest-virt-server-opt --qemu-architecture=aarch64 \ --autopkgtest-virt-server-opt --ram-size=2048 \ --autopkgtest-virt-server-opt --cpus=4 \ --autopkgtest-virt-server-opt=--debug \ --autopkgtest-virt-server-opt IMAGEFILE src.dsc
Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
On 2022-01-12 20:14, Christian Kastner wrote: > Addendum: I'm now occasionally also seeing this with arm64 when using > sbuild with --chroot-mode=autopkgtest. I'd say it's 50/50 between > success and failure. Yet another data point: by reducing the CPU count to 1, it seems that the success rate climbs to 100% on arm64. No idea why this would have an effect on the communication with the VM. That didn't work for armhf, though. > $ sbuild --arch arm64 --dist unstable \ > --bd-uninstallable-explainer apt \ > --chroot-mode=autopkgtest --autopkgtest-virt-server=qemu \ > --autopkgtest-virt-server-opt --overlay-dir=/tmp \ > --autopkgtest-virt-server-opt --qemu-architecture=aarch64 \ > --autopkgtest-virt-server-opt --ram-size=2048 \ > --autopkgtest-virt-server-opt --cpus=1 \ ^^^ > --autopkgtest-virt-server-opt=--debug \ > --autopkgtest-virt-server-opt IMAGEFILE src.dsc
Bug#1003002: autopkgtest-virt-qemu: Console setup issue on armhf
Package: autopkgtest Version: 5.19 Severity: normal It looks as if one of the necessary consoles is not set up properly on armhf (it worked fine for me on arm64): $ sudo autopkgtest-build-qemu \ --architecture armhf \ --mirror http://deb.debian.org/debian \ unstable armhf.img ... $ autopkgtest libocas -- qemu \ --dpkg-architecture armhf \ -d --show-boot \ armhf.img produces | host login: autopkgtest-virt-qemu: DBG: expect: found "'login prompt on serial console'" | autopkgtest-virt-qemu: DBG: expect: b'ok' | autopkgtest-virt-qemu: DBG: setup_shell(): no default shell on hvc1 or ttyS1 | qemu-system-arm: terminating on signal 15 from pid 1316826 (/usr/bin/python3) | autopkgtest-virt-qemu: DBG: cleanup... | : failure: The VM does not start a root shell on ttyS1 or hvc1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0 [By the way, libocas is just a tiny library with no dependencies that I tend to use as a smoke test.] Best, Christian
