In case this is not just related to VirtualBox

FinalBlocker +1

I've been unable to reproduce on in my own testing using QEUM, Hyper-V & bare metal.

FinalBlocker -1
FinalFE +1

Have not been able to repro.

FinalBlocker -1

FinalFE +1

unable to reproduce

FinalBlocker -1

This doesn't seem super widespread.

FinalBlocker -1
FinalFE +1

FinalBlocker -1
FinalFE +1

never have seen this issue

I was able to reproduce in a QEMU/KVM guest (see my comments in https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/8296 ), but I could work around it by first logging out, then powering off from the GDM screen.

Discussed during the 2025-03-31 blocker review meeting [1]:

• AGREED: 2355033 - punt (delay decision) on blocker status, AcceptedFreezeException (Final) - after some discussion of the details behind this bug, we're not sure whether to block on it. The worst case is when something not tracked by GNOME is inhibiting shutdown; in this case, shutdown fails without explanation. But that will not usually be the case, and in at least some cases, the new behaviour is probably better than the old behaviour (e.g. it wasn't good that you could happily shut down while a package install operation was happening outside of GNOME). we will punt this to try and investigate specific triggers to aid in deciding whether to block. It's clearly desirable to improve this behaviour during freeze if we can, though, so this is accepted FE.

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-03-31/f42-blocker-review.2025-03-31-16.01.log.html

AGREED AcceptedFinalFE

The following votes have been closed:

• Accepted FinalFreezeException (+4, 0, -0)
  • +1 by boniboyblue, asciiwolf, nielsenb, lruzicka

This upstream issue implies this is an incompatibility between gnome-session and the latest systemd. It's unfortunate for sure, but it is apparently intermittent, and can be worked around.

FinalBlocker -1

FinalBlocker -1

After reading the upstream ticket, I agree this is annoying, but I don't think it qualifies as a blocker. We could document the workaround for apps that have a desktop icon, IIUC. But Kamil does raise a good point on the blocker meeting that if a process doesn't have a desktop icon assigned then the user may have no other option (?) than to force power-off. Which is a big hammer.

Discussed during the 2025-04-07 blocker review meeting [1]:

• AGREED: 2355033 - Rejected FinalBlocker - This is a conditional violation of our poweroff criterion. We haven't found evidence that it would happen too frequently or in too many use cases. For that reason, we reject it as a final blocker. If there's new evidence that it's happening much more often, we can reconsider the blocker vote.

[1] https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-04-07/f42-blocker-review.2025-04-07-16.01.log.html

AGREED RejectedFinalBlocker

The following votes have been closed:

• Rejected FinalBlocker (+1, 0, -6)
  • +1 by augenauf
  • -1 by boniboyblue, derekenz, geraldosimiao, nielsenb, lruzicka, kashyapc

Release F42 is no longer tracked by BlockerBugs, closing this ticket.