Bug details: https://bugzilla.redhat.com/show_bug.cgi?id=2063156 Information from BlockerBugs App: <img alt="2063156" src="https://qa.fedoraproject.org/blockerbugs/api/v0/bugimg/2063156" />
Commented but haven't voted yet: coremodule, feborges
The votes have been last counted at 2022-04-11 21:19 UTC and the last processed comment was #comment-791835
To learn how to vote, see: https://pagure.io/fedora-qa/blocker-review A quick example: BetaBlocker +1 (where the tracker name is one of BetaBlocker/FinalBlocker/BetaFE/FinalFE/0Day/PreviousRelease and the vote is one of +1/0/-1)
BetaBlocker +1
BetaBlocker
FinalBlocker
BetaFE
FinalFE
0Day
PreviousRelease
+1
0
-1
FYI: The fix can be also "switching the default from QXL to virtio"
I just created a new VM it virt-manager and it defaults to Video Virtio, not sure when it changed. -1 BetaBlocker
BetaBlocker -1
Works for me with VirtIO, which also seems to now be the default...? Also seems to work with QXL now as mentioned in the ticket.
I just created a new VM it virt-manager and it defaults to Video Virtio, not sure when it changed.
As per the bug report, virtio seems to be the default from virt-manager 4.0, which is currently in updates-testing for F36. For F35, there is virt-manager 3.2 defaulting to qxl. Please test this on F35, thanks.
So this is apparently a race. See more info in the bug report.
I could not reproduce this behavior on an F36 system at all, on neither QXL nor Virtio driver. I understand that on F35, this could be pretty annoying when somebody wants to try out Beta in a VM, but since the workaround seems to be pretty easy, the application is still functional and therefore I believe a common bugs entry could do with it.
BetaBlocker -1 BetaFreezeException +1
Hmm, if anything, it'd then be previous release blocker?
BetaBlocker -1 Hmm, if anything, it'd then be previous release blocker?
No no, if a release does not run on a currently stable release (which for Kamil is true) than it is breaking the Basic Criterion:
https://fedoraproject.org/wiki/Basic_Release_Criteria#Guest_on_current_stable_release
AGREED RejectedBetaBlocker
Discussed during the 2022-03-14 blocker review meeting: [0]
The decision to classify this bug as a "RejectedBlocker (Beta)" was made as this is pretty bad, but since it apparently doesn't happen consistently in the most common config (system virt session) and is easy to workaround (use virtio), we think it's not bad enough to block Beta.
[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-14/f36-blocker-review.2022-03-14-16.01.txt
The following votes have been closed:
The decision to delay the classification of this as a blocker bug was made as we were not able to reach a clear decision at this time and with the information currently available. We'll aim to have more folks test and hopefully get feedback from the developers on what may be going on here.
BetaBlocker -1 Hmm, if anything, it'd then be previous release blocker? No no, if a release does not run on a currently stable release (which for Kamil is true) than it is breaking the Basic Criterion: https://fedoraproject.org/wiki/Basic_Release_Criteria#Guest_on_current_stable_release
The fix, however, can (should?) happen in Previous Release (updating virt-manager to >= 4.0), not in F36, so it won't be F36 blocker (because there is nothing to change in F36). If that turns out to be the case, it can't be F36 Blocker, only Previous Release Blocker as specified in https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Normal.2C_0-Day_and_Previous_Release_blockers .
Updating F35's (and F34's!) virt-manager is just a workaround. The real problem is most probably somewhere in GNOME stack (mutter, libinput, etc) in F36.
AGREED AcceptedBetaFE
Discussed during the 2022-03-21 blocker review meeting: [0]
The decision to delay the classification of this as a Final Blocker bug was made as it's still not clear how common this bug is, so we can't really make a Final blocker determination yet. We will try to test it further after the meeting. We do accept it as a Beta freeze exception, just in case the fix is in the client side and shows up soon.
[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-21/f36-blocker-review.2022-03-21-16.01.txt
It doesn't feel real common to me? We've had multiple beta composes with what looks like decent VM test coverage (admittedly we don't always know what people are using as a host), and It looks to me like only @kparal can somewhat reliably reproduce. I have been unable to reproduce across multiple machines and installs.
Until it looks like a more common occurence, I don't see it as blocker material (looks nervously for horde of new reporters when beta releases).
Definite common bugs material however.
FinalBlocker -1 FinalFE +1
There's only a handful people present in the release validation matrices. They might be using F36, or Boxes, or they might have their VMs configured with virtio (because we've had issues with qxl in the past, and so people might have edited their VMs - I only had qxl because I have a new laptop with a fresh Fedora installation, on my old laptop all my VMs had virtio). So it's hard to draw any conclusions. It will be interesting to look for reports from Beta testers, yes.
AGREED AcceptedFinalBlocker
Discussed during the 2022-03-28 blocker review meeting: [0]
The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:
"A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop...", when running on a default F35 or earlier virt-manager VM and hitting the bug.
[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-03-28/f36-blocker-review.2022-03-28-16.00.txt
Pushing this update should be enough to work around this bug: https://bodhi.fedoraproject.org/updates/FEDORA-2022-fec53b10e3
What about Boxes? I can't even set virtio video there...
REVOTE FinalBlocker
Workaround https://bodhi.fedoraproject.org/updates/FEDORA-2022-fec53b10e3 landed in F35.
If I am not mistaken, Boxes used virtio by default for a long time.
For me, it uses QXL...
Weird, just retested on two different machines (F36 hosts both), just virtio, I don't know then :/
For me, it uses QXL... Weird, just retested on two different machines (F36 hosts both), just virtio, I don't know then :/
I'm on F34 and F35 hosts. I don't have an F36 host yet.
Could you please file an upstream bug sharing the libvirt domain XML for this VM? If the VM got detected as "Fedora", it should be using virtio-gpu ever since Fedora 24.
FinalBlocker -1
It looks like, post-workaround, the reproducibility is unclear enough for me to not consider it a blocker.
Looks like the main issue is worked around well enough.
I guess the workaround is sufficient to not block on this.
AGREED AcceptedFinalFE Decided on meeting https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-11/f36-blocker-review.2022-04-11-16.00.log.txt
Metadata Update from @blockerbot: - Issue status updated to: Closed (was: Open)
Release F36 is no longer tracked by BlockerBugs, closing this ticket.
Log in to comment on this ticket.