Problems with tuxrun on Fedora

***In GitLab by @linusw on Sep 9, 2025, 13:09 GMT+1:***

I'm trying to run FVP through tuxrun (pip3 installed) on Fedora 42 and there are problems:

tuxrun --runtime podman --device fvp-aemva --boot-args "rw" --kernel ./Image.gz --rootfs https://storage.tuxboot.com/debian/trixie/arm64/rootfs.ext4.xz --modules ./modules.tar.xz /usr/ --save-outputs --log-file -
tuxrun-66z1_bk9
2025-09-08T22:34:28 lava-dispatcher, installed at version: 2024.09.dev0173
2025-09-08T22:34:28 start: 0 validate
2025-09-08T22:34:28 Start time: 2025-09-08 22:34:28.927102+00:00 (UTC)
2025-09-08T22:34:28 Validating that file:///tmp/tuxrun-66z1_bk9/startup.nsh exists
2025-09-08T22:34:28 Validating that https://storage.tuxboot.com/buildroot/fvp-aemva/FVP_AARCH64_EFI.fd exists
2025-09-08T22:34:29 Validating that https://storage.tuxboot.com/buildroot/fvp-aemva/bl1.bin exists
2025-09-08T22:34:29 Validating that https://storage.tuxboot.com/buildroot/fvp-aemva/fvp-base-revc.dtb exists
2025-09-08T22:34:29 Validating that file:///home/linus/.cache/tuxmake/builds/24/Image.gz exists
2025-09-08T22:34:29 Validating that file:///home/linus/.cache/tuxrun/assets/https___storage.tuxboot.com_debian_trixie_arm64_rootfs.ext4.xz exists
2025-09-08T22:34:29 Validating that file:///home/linus/.cache/tuxmake/builds/24/modules.tar.xz exists
2025-09-08T22:34:29 Validating that https://storage.tuxboot.com/buildroot/fvp-aemva/fip.bin exists
2025-09-08T22:34:29 validate duration: 0.96
2025-09-08T22:34:29 {'definition': 'lava', 'case': 'validate', 'result': 'fail'}
2025-09-08T22:34:29 Cleaning after the job
2025-09-08T22:34:29 Stopping container tuxrun-66z1_bk9-lava-1 from action check-fvp-version
2025-09-08T22:34:29 Calling: ['docker', 'stop', 'tuxrun-66z1_bk9-lava-1']
2025-09-08T22:34:30 >> Error: no container with name or ID "tuxrun-66z1_bk9-lava-1" found: no such container
2025-09-08T22:34:30 Returned 125 in 0 seconds
2025-09-08T22:34:30 Stopping container tuxrun-66z1_bk9-lava-1 from action run-fvp
2025-09-08T22:34:30 Calling: ['docker', 'stop', 'tuxrun-66z1_bk9-lava-1']
2025-09-08T22:34:30 >> Error: no container with name or ID "tuxrun-66z1_bk9-lava-1" found: no such container
2025-09-08T22:34:30 Returned 125 in 0 seconds
2025-09-08T22:34:30 Removing root tmp directory at /var/lib/lava/dispatcher/tmp/tuxrun-66z1_bk9-1
2025-09-08T22:34:30 Unable to remove the directory: Permission denied
2025-09-08T22:34:30 JobError: Your job cannot terminate cleanly.
2025-09-08T22:34:30 {'definition': 'lava', 'case': 'job', 'result': 'fail', 'error_msg': 'Invalid job data: ["Image file \'/home/linus/.cache/tuxrun/assets/https___storage.tuxboot.com_debian_trixie_arm64_rootfs.ext4.xz\' does not exist or is not readable"]\n', 'error_type': 'Job'}
tuxrun-66z1_bk9
TuxRun outputs saved to /home/linus/.cache/tuxrun/tests/7
E: hook `tuxrun --runtime podman --device fvp-aemva --boot-args "rw" --kernel ./Image.gz --rootfs https://storage.tuxboot.com/debian/trixie/arm64/rootfs.ext4.xz --modules ./modules.tar.xz /usr/ --save-outputs --log-file -` failed with exit code 1

Other trial run with just tuxmake:

$ tuxrun --runtime podman --device fvp-aemva --boot-args "rw" --kernel ~/.cache/tuxmake/builds/24/Image.gz --rootfs https://storage.tuxboot.com/debian/trixie/arm64/rootfs.ext4.xz --modules ~/.cache/tuxmake/builds/24/modules.tar.xz /usr/ --save-outputs --log-file -
tuxrun-ym66n5sb
Error: setting up Pasta: pasta failed with exit code 1:
Couldn't open PID file /run/user/1001/containers/networks/rootless-netns/rootless-netns-conn.pid: Permission denied
TuxRun outputs saved to /home/linus/.cache/tuxrun/tests/8

It's a bit hard to pin down the actual problems because it tends to change, best way to replicate is probably to just try and use the pip3 version on Fedora 42 and see what happens.

*Migrated from GitLab: https://gitlab.com/Linaro/tuxrun/-/issues/36*

Reproduce the reported tuxrun commands using the pip3 version on Fedora 42, with the Podman runtime and fvp-aemva device. Investigate the missing rootfs asset, the Pasta PID-file permission failure, and the unsuccessful container cleanup; done means the command runs or reports one clearly diagnosed, reproducible failure.

Written by the indexing model from the issue text.