Out of curiosity I looked at the Serial 1 console output (View → Consoles → Serial 1) and this is the last output before the something seemingly hangs infinitely:
The very last line says ASSERT [RngDxe] BaseArmTrngLibNull.c(86): ((BOOLEAN)(0==1)). Looking for this online brought me to this: https://issues.redhat.com/browse/RHEL-88088, which links to this pull request supposed to fix the issue: ArmVirt: move Defines section to new include file by kraxel · Pull Request #10997 · tianocore/edk2 · GitHub
Unfortunately, I do not fully understand what the discussions is about. The comment by Gerd Hoffman:
It’s broken in case the cpu has no rndr instruction support, because the fallback to platform rng device does not work
With a bit of further research, I interpret this the following way: The rndr instruction is supported by the CPU, but the CPU claims the instruction is not supported because the random number generator that should be connected to the CPU (by those who design the platform) does not work (see Random).
From the pull request , I understand that the order in with some cookie libraries (?) are picked causes the issue. As the pull request is for TianoCore (the bios used by the virtual machine, see first post, second image), I am hopeful that the issue will be solved when builds (of TianoCore) are available in “June” and find their way into Tumbleweed soon after.
Assuming qemu-uefi-aarch64 contains TianoCore, I thought I could downgrade (something I never tried) to see if the above holds, but that seems not as easy as i though:
(It also seems not necessarily advisable, given risk of breakages and security: How to (re-) install software of older versions of openSUSE? - #8 by hui)