So I looked a bit more into the failing ARM test on Rawhide. I extended the timeout for the test on staging to 1200 (which gets multiplied by the scaling factor so it winds up being 6000). That lets the test get farther, but it still fails.
It looks like the system is getting stuck running an fsck at boot, and systemd eventually times out and fails the boot because the fsck takes too long. In https://openqa.stg.fedoraproject.org/tests/63905#step/install_arm_image_deployment/8 you see it starting the fsck, in https://openqa.stg.fedoraproject.org/tests/63905#step/install_arm_image_deployment/9 we can see it's been running for 15 minutes, and by https://openqa.stg.fedoraproject.org/tests/63905#step/install_arm_image_deployment/10 we can see the 'Local File Systems' target failing because various devices haven't shown up.
Compare to the f25 Final test: https://openqa.fedoraproject.org/tests/48478 . If we look at the video for that test, we can see the same fsck does actually *happen*, but it completes within the space of 3 seconds: we see 'Starting File System Check' between 168.441856 and 169.935881, and 'Started File System Check' between 169.935881 and 171.030909.
So obviously something very different happens to the fsck process between f25 and Rawhide, but I'm not sure why. Could be some issue in the image compose process means the filesystem is actually inconsistent and has to be fixed, and that takes forever in emulation. But it needs looking into. Could you please recreate the test manually and figure out what's going on with the fsck? Thanks.