Hide Forgot
Created attachment 1870110 [details] screencast1 Description of problem: Boot Fedora-Workstation-Live-x86_64-36-20220401.n.0.iso on a VM with QXL video driver,anaconda failed to start a live session almost all the time. I tried 12 times, anaconda only boot into the Welcome page successfully once. in 7 attempts, everything will be okay, after I click "Live System User"(screencast1),in the other 4 attempts,the system get stuck after I click "Live System User"(screencast2) Like https://bugzilla.redhat.com/show_bug.cgi?id=2063156,KDE is not affected,but there seems no difference between user session and system session. This bug is only affected workstation live iso 0329 and later,but Fedora-Workstation-Live-x86_64-36-20220329.n.1.iso and Fedora-Workstation-Live-x86_64-36-20220328.n.0.iso have the same mutter version. I boot 0328 workstation iso 10 times on the same VM,didn't see this bug. Version-Release number of selected component (if applicable): Fedora-Workstation-Live-x86_64-36-20220401.n.0.iso: gnome-shell-42.0-2.fc36.x86_64 gtk3-3.24.31-2.fc36.x86_64 mutter-42.0-2.fc36.x86_64 anaconda-36.16.2-4.fc36.x86_64 Fedora-Workstation-Live-x86_64-36-20220328.n.0.iso: gnome-shell-42~rc-3.fc36.x86_64 gtk3-3.24.31-2.fc36.x86_64 mutter-42~rc-5.fc36.x86_64 anaconda-36.16.2-4.fc36.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1870111 [details] screencast2
Created attachment 1870112 [details] screencast2
Created attachment 1870113 [details] journal
Proposed as a Blocker for 36-final by Fedora user lnie using the blocker tracking app because: This seems violate this criteria: The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release,as the VM is hosted on f35 system
The obvious thing that changed in 20220329.n.1 is this GNOME 42 Final update: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a69718b1e1 it didn't include mutter or gnome-shell, but it did include almost everything else. I guess glib2, gnome-session, or gnome-settings-daemon may be involved.
Testing with Fedora-Workstation-Live-x86_64-36-20220402.n.0.iso I can't seem to reproduce this. In a VM with qxl graphics it boots fine to the live user session every time for me, and launched anaconda successfully. Tried it four times.
I can reproduce this behaviour. I have tried 10 times with the following results: * 9 times, Anaconda did not start automatically and only GDM was shown instead. * 5 times, user could use GDM to log into the live session and continue installation * 4 times, the system hung after a log-in attempt. * 1 time, system got stuck without any possible interaction possible.
I tested with Fedora-Workstation-Live-x86_64-36-20220404.n.0.iso. With virtio I tested 6 times, worked perfectly. With qxl, I tested 10 times: * 1 time everything worked ok * 8 times gdm was shown, but after login everything worked ok * 1 time gdm was shown, but after login the session seemed stuck. But it wasn't! It was exactly the same problem as in bug 2063156 - all input was ignored, except Escape, which could be used to close the welcome dialog. I suppose both Lili and Lukas, who reported stuck systems, would also be able to use Escape. So what we have here is another bug on top of bug 2063156, which breaks autologin. And once you log in, you have a certain chance to trigger bug 2063156.
Discussed during the 2022-04-04 blocker review meeting: [1] The decision to classify this bug as an AcceptedBlocker was made: After some in-meeting testing by lruzicka, we are under the impression that this is a different bug than 2063156. We accept it as a blocker as it violates this criterion: “The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release. “ [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-04/f36-blocker-review.2022-04-04-16.00.log.html
How much RAM do you guys have configured on your VMs? I have 4G on the one I tested with...
I have 3G RAM and 3 CPU. I also have View->Scale Display: Always and "Auto resize VM with window": Off. After each cycle I do "Force Off" on the VM (I never do "Force Reset"). Oooh, and I just found out the reason why it ends up in gdm so often! It doesn't. Hit Ctrl+Alt+F2 and you'll get switched to the logged in liveuser session! It's just another case of bug 2071394 (also see https://ask.fedoraproject.org/t/21076 ) ! The autologin worked, but then the session got switched to gdm. It's just so quick that you don't notice.
virt-manager change to virtio was merged for f35: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fec53b10e3
> How much RAM do you guys have configured on your VMs? I have 4G on the one I tested with... 2G RAM(which is the default one),I tried with 4G RAM before I reported this bug,seems doesn't help,I tried three times,gdm is shown every time. > Hit Ctrl+Alt+F2 and you'll get switched to the logged in liveuser session yes,confirmed just now > I suppose both Lili and Lukas, who reported stuck systems, would also be able to use Escape Nothing happens after I press Esc
Lifting AcceptedBlocker as workaround https://bodhi.fedoraproject.org/updates/FEDORA-2022-fec53b10e3 landed in F35.
Frantisek, I guess you meant to erase the blocker proposal as well, doing that now.
(In reply to Kamil Páral from comment #15) > Frantisek, I guess you meant to erase the blocker proposal as well, doing > that now. I did not, for more context, it's possible that GNOME Boxes would fallback to QXL, I'll assess the potential situations and we can discuss this next meeting.
Discussed during the 2022-04-11 blocker review meeting: [1] The decision to classify this bug as an AcceptedFreezeException was made: "It is a noticeable issue that cannot be fixed with an update." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-11/f36-blocker-review.2022-04-11-16.00.log.txt
Bug 2063156 was resolved, and it should most probably resolve also this one. Lili, can you please test with a new ISO from 2022-04-21 compose (when it's available)? It should contain gnome-shell-42.0-3.fc36 which should fix it. Thanks.
Kamil,downloaded the iso you created,tried 6 times, didn't see this bug anymore,so closing