Using the aforementioned branch, I managed to have a cross-architecture test run on my machine successfully.
Two things:
To get the test to pass, I need to increase the `timeout-reboot` parameter, giving me the following command line:
`autopkgtest -a armhf gzip -- qemu --timeout-reboot 90 autopkgtest-noble-armhf.img`
Indeed, running the tests in emulation can be quite long, and the default timeout is only 60 seconds, which is quite short for booting a whole system up to the login prompt. (About 65-75 seconds on my machine)
To manually boot the armhf image, here is a working command line:
```
qemu-system-arm \
-machine virt -m 3G -smp 1 -nographic \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0,id=rng-device0 \
-drive if=pflash,format=raw,unit=0,read-only=on,file=/usr/share/AAVMF/AAVMF32_CODE.fd \
-device virtio-net-pci,netdev=eth0 \
-netdev user,id=eth0,hostfwd=tcp::8022-:22 \
-drive file=autopkgtest-noble-armhf.img,if=virtio,format=qcow2
```
A firmware bug indeed prevents using more than 3G of memory, giving the stack trace I saw.
Using the aforementioned branch, I managed to have a cross-architecture test run on my machine successfully.
Two things:
To get the test to pass, I need to increase the `timeout-reboot` parameter, giving me the following command line: noble-armhf. img`
`autopkgtest -a armhf gzip -- qemu --timeout-reboot 90 autopkgtest-
Indeed, running the tests in emulation can be quite long, and the default timeout is only 60 seconds, which is quite short for booting a whole system up to the login prompt. (About 65-75 seconds on my machine)
To manually boot the armhf image, here is a working command line: filename= /dev/urandom, id=rng0 \ rng-pci, rng=rng0, id=rng- device0 \ format= raw,unit= 0,read- only=on, file=/usr/ share/AAVMF/ AAVMF32_ CODE.fd \ net-pci, netdev= eth0 \ eth0,hostfwd= tcp::8022- :22 \ t-noble- armhf.img, if=virtio, format= qcow2
```
qemu-system-arm \
-machine virt -m 3G -smp 1 -nographic \
-object rng-random,
-device virtio-
-drive if=pflash,
-device virtio-
-netdev user,id=
-drive file=autopkgtes
```
A firmware bug indeed prevents using more than 3G of memory, giving the stack trace I saw.