Currently it seems the cited criterion is not violated, because no crash error dialog appears. If I'm mistaken, I'll adjust my vote.

FinalBlocker -1

This to me stops login of a desktop session so seems like a blocker to me.

FinalBlocker +1

FinalBlocker +1

FinalBlocker +1

I have seen the crash in the journalctl and in Abrt. I did not see any notification, but this should not be happening.

FinalBlocker +1

I did not see any notification, but this should not be happening.

Well then, please show us a criterion that this is violating. Because crashes in the background are pretty frequent. The criterion requires the notification intentionally, it's a polish criterion. It doesn't attempt to prevent any crashes. If the crash is benign, it makes no sense to block on it.

So either a notification needs to be there, or you need to demonstrate some other criterion violation.

I stand firm with my -1 FinalBlocker at this moment. There is some report here about other issues, but I don't understand what Peter means by it. If we can see an actual harmful effect, then it makes sense to discuss this (but not focused on the polish criterion).

It should at least definitely be a FinalFE. Things like this one are not necessary blocking, but they make Fedora look unfinished and unprofessional.

FinalBlocker -1
unless more info is provided (i.e. Peter explains how this could cause login failure on the pinebook pro when it doesn't appear to cause it for any other tested case).

What I'm seeing isn't something I would block on. I do see an eventual crash report in abort after running Workstation RC1.4 for several minutes.

FinalBlocker -1

As I commented in the bug abrt won't display popups if the logged in user doesn't have sufficient permissions to see crashes outside their context. That is why some people don't see the release blocking criteria being violated. Which implies a larger problem, around "it can crash all it wants in critical services and the user won't be notified if they are unprivileged" which should probably be fixed at some point too.

AGREED Delayed Decision (Punt)

Discussed at the blocker review meeting on 20th Oct. 2025

We didn't reach a clear consensus on this with the folks present in the meeting. vote currently stands at +2 / -4. We have, for now, filed a separate bug for Peter Robinson's Pinebook Pro issue - https://bugzilla.redhat.com/show_bug.cgi?id=2405144 - and we're awaiting further details on that.

https://meetbot.fedoraproject.org/blocker-review_matrix_fedoraproject-org/2025-10-20/f43-blocker-review.2025-10-20-16.02.html

As I commented in the bug abrt won't display popups if the logged in user doesn't have sufficient permissions to see crashes outside their context. That is why some people don't see the release blocking criteria being violated. Which implies a larger problem, around "it can crash all it wants in critical services and the user won't be notified if they are unprivileged" which should probably be fixed at some point too.

That's intentional for security reasons: a non-privileged user should NOT be getting information about what may or may not be malfunctioning in an escalated environment. Now, if members of the wheel group aren't being notified, I agree with you. But a basic, non-privileged user shouldn't see system errors.

Based on what I'm seeing here, it doesn't sound like this would pass the "Final Blocker" test to me: it's not causing any obvious misbehavior (the potential PineBook issue may be unrelated and is being investigated separately), it's a late blocker and its hardware impact is quite limited.

FinalBlocker -1

That's intentional for security reasons: a non-privileged user should NOT be getting information about what may or may not be malfunctioning in an escalated environment. Now, if members of the wheel group aren't being notified, I agree with you. But a basic, non-privileged user shouldn't see system errors.

Users created as part of the initial setup process are wheel users by default these days so for normal testing a basic user is a wheel level privileged user.

That's intentional for security reasons: a non-privileged user should NOT be getting information about what may or may not be malfunctioning in an escalated environment. Now, if members of the wheel group aren't being notified, I agree with you. But a basic, non-privileged user shouldn't see system errors.

Users created as part of the initial setup process are wheel users by default these days so for normal testing a basic user is a wheel level privileged user.

It's not clear to me that this is a wheel-level privileged user from the description. If it is a wheel user, then I agree that's not desired behavior.

Just tested an install of Workstation RC1.4. The crash appears under the "System" tab in Problem Reporter, and is viewable by entering the password for privilege escalation.

All of this was with the the user created during initial setup, which is a member of the wheel group.

Other than the crash (which has no negative effects that I've found), everything seems to be working exactly as designed.

Just tested an install of Workstation RC1.4. The crash appears under the "System" tab in Problem Reporter, and is viewable by entering the password for privilege escalation.

All of this was with the the user created during initial setup, which is a member of the wheel group.

Other than the crash (which has no negative effects that I've found), everything seems to be working exactly as designed.

Did you receive a desktop notification of the crash, or did you have to specifically go looking for it?

Just tested an install of Workstation RC1.4. The crash appears under the "System" tab in Problem Reporter, and is viewable by entering the password for privilege escalation.

All of this was with the the user created during initial setup, which is a member of the wheel group.

Other than the crash (which has no negative effects that I've found), everything seems to be working exactly as designed.

Did you receive a desktop notification of the crash, or did you have to specifically go looking for it?

You have to open Problem Reporter. No desktop notification.

FinalBlocker -1

FinalBlocker -1

FWIW: This is still in the F43 1.6 RC

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