After verifying the media and booting, the system eventually boots to an unusable, graphically corrupted desktop. It is possible the graphical session is frozen as well, as I am unable to make the corruption pattern change. Reproducible: Always Steps to Reproduce: 1. Write 20240117.n.0 Workstation Live compose to USB drive 2. Select USB drive to boot 3. Select "Test this media and boot Fedora Workstation Live" 4. Wait for verification and boot to complete Actual Results: System boots to an unusable, graphically corrupted desktop. Expected Results: Desktop is displayed correctly. Tested using the 20240117.n.0 compose[0]. Hardware tested: HP Compaq 8510w laptop (BIOS), Intel T9300 CPU, AMD RV630 GPU (so using radeon, not amdgpu). Switching to a virtual console works, but I do not know how to sign into a live session for log collection. The matching KDE compose[1] functions correctly, so I am tagging mutter as the component. [0] - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240117.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20240117.n.0.iso [1] - https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240117.n.0/compose/Spins/x86_64/iso/Fedora-KDE-Live-x86_64-Rawhide-20240117.n.0.iso
Still seen with 20240130.n.0 compose: https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20240130.n.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20240130.n.0.iso
Proposed as a Blocker for 40-beta by Fedora user nielsenb using the blocker tracking app because: It is not possible to perform an installation with the corrupted display, which is a violation of the "Installation interfaces" [basic criteria](https://fedoraproject.org/wiki/Basic_Release_Criteria#Installation_interfaces).
"Switching to a virtual console works, but I do not know how to sign into a live session for log collection." You can just log in as 'root' with no password. Just enter 'root' as the username and you'll be logged in right away. We will need logs to debug this, of course.
(In reply to Adam Williamson from comment #3) > "Switching to a virtual console works, but I do not know how to sign into a > live session for log collection." > > You can just log in as 'root' with no password. Just enter 'root' as the > username and you'll be logged in right away. We will need logs to debug > this, of course. Wow, let's all just pretend that's the first thing I tried... :D Attaching a log (journal_20240130_n_0) from a garbled display boot. I don't necessarily see anything out of the ordinary except a likely unrelated page fault in the wireless driver. I also see both "radeon" and "amdgpu" seem to report "kernel modesetting enabled".
Created attachment 2014077 [details] Journal from boot with a garbled display
hmm, yeah, I don't see any very obvious smoking guns either. we do have an Unfortunate Situation(tm) in Rawhide ATM which means new kernel builds aren't going stable, so we've been on the same very early 6.8 snapshot for some time (both your Jan 17 test and the one today likely used the same kernel). Can you try with https://openqa.fedoraproject.org/tests/2384487/asset/iso/02384487-Fedora-Workstation-Live-x86_64-FEDORA-2024-cba88e0da6.iso and see if that works? That's a Workstation live with the most recent attempted kernel build (better grab it fast, the ISO will be garbage-collected relatively soon). thanks!
(In reply to Adam Williamson from comment #6) > hmm, yeah, I don't see any very obvious smoking guns either. > > we do have an Unfortunate Situation(tm) in Rawhide ATM which means new > kernel builds aren't going stable, so we've been on the same very early 6.8 > snapshot for some time (both your Jan 17 test and the one today likely used > the same kernel). Can you try with > https://openqa.fedoraproject.org/tests/2384487/asset/iso/02384487-Fedora- > Workstation-Live-x86_64-FEDORA-2024-cba88e0da6.iso and see if that works? > That's a Workstation live with the most recent attempted kernel build > (better grab it fast, the ISO will be garbage-collected relatively soon). > thanks! Same end result with that version. No amdgpu reporting modesetting is enabled though, just radeon.
Can confirm that this happens on our test machine with AMD Radeon HD 6500 running radeon driver. With nomodeset I was able to boot to graphical desktop. Slimbook with intel/nvidia GPU is not affected.
Just on the offchance this happens to be the same thing as https://bugzilla.redhat.com/show_bug.cgi?id=2261842 , can you try with kernel-6.8.0-0.rc3.20240208git047371968ffc.30.fc40 and/or mutter-46~alpha-5.fc40 ?
I no longer see this with the 20240210.n.1 compose.
That's great news! Lukas, how about ours?
Our machine works fine with 20240210.n.1 compose.
Discussed during the 2024-02-12 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as there are strong indications that this is fixed by a recent kernel, mesa and/or mutter update, so we are punting in the expectation it will be closed as fixed with confirmation from lbrabec soon. If not, we will reconsider it next time. [0] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2024-02-12/f40-blocker-review.2024-02-12-17.05.txt
Thanks Lukas, so let's call this fixed.