Created attachment 1754546 [details] backtrace of the crash In recent Rawhide composes, when gnome-initial-setup runs on first boot after install (from both Workstation live and Silverblue installer), gnome-shell (which it runs on top of) crashes shortly after g-i-s starts. The backtrace points to mesa, and the bug started in Fedora-Rawhide-20210130.n.0, the first compose after mesa-21.0.0~rc3-1.fc34 landed in Rawhide, so filing against mesa. openQA VMs use qemu with the 'virtio' adapter. Attaching the backtrace.
I've just done a system upgrade to rawhide in virgl enabled VM and created a new user and g-i-s ran fine with no gnome-shell crashes. I'll see if I can reproduce using an composed installer.
I think the issue is actually just gnome-shell is crashing a lot in the openQA config at least, there's some other tests where it managed to get through g-i-s but then failed later ultimately apparently still because gnome-shell is crashing. If it crashes in g-i-s we get an "oh no!" screen but there seems to be another failure mode where the test makes it through g-i-s but then Shell apparently crashes and auto-restarts on a loop while displaying the Welcome Tour, e.g. https://openqa.fedoraproject.org/tests/767773 - you can see it from the screenshots and also in the video, https://openqa.fedoraproject.org/tests/767773/video?filename=video.ogv , that at the end it just keeps cycling between a blank grey screen and the welcome tour. I haven't backtraced the coredump from that test yet but I'd bet it'll turn out to be the same thing. the qemu command line from the test that I did backtrace was: /usr/bin/qemu-system-x86_64 -vga virtio -only-migratable -chardev ringbuf,id=serial0,logfile=serial0,logappend=on -serial chardev:serial0 -audiodev none,id=snd0 -device intel-hda -device hda-output,audiodev=snd0 -global isa-fdc.driveA= -m 2048 -cpu Nehalem -netdev user,id=qanet0,net=172.16.2.0/24 -device virtio-net,netdev=qanet0,mac=52:54:00:12:34:56 -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 -device usb-ehci -device usb-tablet -smp 2 -enable-kvm -no-shutdown -vnc :93,share=force-shared -device virtio-serial -chardev pipe,id=virtio_console,path=virtio_console,logfile=virtio_console.log,logappend=on -device virtconsole,chardev=virtio_console,name=org.openqa.console.virtio_console -chardev socket,path=qmp_socket,server,nowait,id=qmp_socket,logfile=qmp_socket.log,logappend=on -qmp chardev:qmp_socket -S -device virtio-scsi-pci,id=scsi0 -blockdev driver=file,node-name=hd0-file,filename=/var/lib/openqa/pool/3/raid/hd0,cache.no-flush=on -blockdev driver=qcow2,node-name=hd0,file=hd0-file,cache.no-flush=on -device virtio-blk,id=hd0-device,drive=hd0,serial=hd0 -blockdev driver=file,node-name=cd0-overlay0-file,filename=/var/lib/openqa/pool/3/raid/cd0-overlay0,cache.no-flush=on -blockdev driver=qcow2,node-name=cd0-overlay0,file=cd0-overlay0-file,cache.no-flush=on -device scsi-cd,id=cd0-device,drive=cd0-overlay0,serial=cd0 -drive id=pflash-code-overlay0,if=pflash,file=/var/lib/openqa/pool/3/raid/pflash-code-overlay0,unit=0,readonly=on -drive id=pflash-vars-overlay0,if=pflash,file=/var/lib/openqa/pool/3/raid/pflash-vars-overlay0,unit=1 if that helps to reproduce the config.
I've built mesa-21.0.0~rc3-2.fc34 in rawhide. It should fix this.
Indeed this does seem to be fixed. Plenty of other test failures to look into, but we made it to the desktop at least!