I did some more tests as I also ran into this problem. Here is what I could find out until now:
I start qemu manually in a similar way as done by autopkgtest with the following command: $ qemu-system-arm -machine virt -m 1024 -smp 1 -display none -net nic,model=virtio -net user,hostfwd=tcp:127.0.0.1:10022-:22 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0,id=rng-device0 -monitor unix:monitor,server=on,wait=off -virtfs local,id=autopkgtest,path=shared,security_model=none,mount_tag=autopkgtest -serial unix:ttyS0,server=on,wait=off -chardev socket,path=hvc0,server=on,wait=off,id=hvc0 -device virtio-serial -device virtconsole,chardev=hvc0 -chardev socket,path=hvc1,server=on,wait=off,id=hvc1 -device virtio-serial -device virtconsole,chardev=hvc1 -chardev socket,path=hvc2,server=on,wait=off,id=hvc2 -device virtio-serial -device virtconsole,chardev=hvc2 -drive index=0,file=overlay-tmp/overlay.img,cache=unsafe,if=virtio,discard=unmap,format=qcow2 -drive if=pflash,format=raw,unit=0,read-only,file=/usr/share/AAVMF/AAVMF32_CODE.fd -drive if=pflash,format=raw,unit=1,file=overlay-tmp/efivars.fd I added a third console hvc2 to illustrate my findings better, see below. Before being able to start this qemu command, I had to do some preparations: $ qemu-img create -f qcow2 -F qcow2 -b /var/local/autopkgtest-unstable-armhf.img overlay-tmp/overlay.img $ cp /usr/share/AAVMF/AAVMF32_VARS.fd overlay-tmp/efivars.fd After starting qemu, I can attach to the serial ports with: $ socat -,echo=0,icanon=0 unix-connect:ttyS0 $ socat -,echo=0,icanon=0 unix-connect:hvc0 $ socat -,echo=0,icanon=0 unix-connect:hvc1 $ socat -,echo=0,icanon=0 unix-connect:hvc2 What I noticed after booting the autopkgtest image is the following: ttyAMA0 inside the vm is ttyS0 outside hvc0 inside the vm is hvc1 outside hcv1 inside the vm is hvc2 outside hvc0 outside the vm doesn't seem to do anything So that's the problem, the hvc console numbers are all shifted by one. If you leave out hvc2 in the qemu command line (to get the same as done by autopkgtest), then hcv1 inside the vm does not exist: "No such device". But there is more interesting stuff: When I log into the vm and execute the following commands, the numbering changes: # rmmod virtio_console # modprobe virtio_console Now hvc0 inside the vm is also hvc0 outside. And the same for hvc1 and hvc2. So everything is now as I would expect it. I have no idea what's going on here. Is this a bug in the Linux kernel? The kernel I did my tests with is 5.16.0-2-armmp-lpae. I could imagine this is a race somewhere, which might also explain Christian's observations with arm64. I still have an old autopkgtest armhf image from Jun 6 2021 that has linux 5.10.0-7-armmp-lpae and doesn't show that behaviour. So some change after that must have broken the console numbering.
signature.asc
Description: This is a digitally signed message part.
