Created attachment 1772778 [details]
File: backtrace

Created attachment 1772779 [details]
File: core_backtrace

Created attachment 1772780 [details]
File: cpuinfo

Created attachment 1772781 [details]
File: dso_list

Created attachment 1772782 [details]
File: environ

Created attachment 1772783 [details]
File: exploitable

Created attachment 1772784 [details]
File: limits

Created attachment 1772785 [details]
File: maps

Created attachment 1772786 [details]
File: mountinfo

Created attachment 1772787 [details]
File: open_fds

Created attachment 1772788 [details]
File: proc_pid_status

This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Similar problem has been detected:

Booting Fedora-Workstation-35-20210824.n.0.aarch64.raw on the PineBook Pro.

reporter:       libreport-2.15.2
backtrace_rating: 4
cgroup:         0::/user.slice/user-984.slice/session-c1.scope
cmdline:        /usr/libexec/gsd-usb-protection
crash_function: get_current_screen_saver_status
executable:     /usr/libexec/gsd-usb-protection
journald_cursor: s=350ff5b3cb6445569b546484e710bd29;i=69d;b=38181054ca4e41939d8a6b9ed107a4d4;m=68d85d1;t=5ca5590cf8a3c;x=ee54bad0ad1c128e
kernel:         5.14.0-0.rc7.54.fc35.aarch64
package:        gnome-settings-daemon-40.0.1-2.fc35
reason:         gsd-usb-protection killed by SIGSEGV
rootdir:        /
runlevel:       unknown
type:           CCpp
uid:            984

Similar problem has been detected:

First boot of Fedora-Workstation-35-20210825.n.0.armhfp.raw image on 32-bit arm.

reporter:       libreport-2.15.2
backtrace_rating: 4
cgroup:         0::/user.slice/user-983.slice/session-c1.scope
cmdline:        /usr/libexec/gsd-usb-protection
crash_function: get_current_screen_saver_status
executable:     /usr/libexec/gsd-usb-protection
journald_cursor: s=00540224818b465bb4f5c200f76e951f;i=629;b=5edd9ff60a1e47ffbfda806f62f2c556;m=d2acf8f;t=5ca4637a1da1a;x=69d1669cbd897dca
kernel:         5.14.0-0.rc7.54.fc35.armv7hl
package:        gnome-settings-daemon-40.0.1-2.fc35
reason:         gsd-usb-protection killed by SIGSEGV
rootdir:        /
runlevel:       unknown
type:           CCpp
uid:            983

This seems to be happening on all arches, on AArch64 when it crashes we get the "Oh no something went wrong" screen, then shortly after gnome-initial-setup is displayed over top and works as expected. Once completed Gnome works as expected. Proposing as a blocker for F35 Beta for cosmetic reasons and discussion.

The gsd-usb-protection crash has been around for a while, and I don't think is actually anything to do with the g-i-s problem. That is tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1997310 . It only started happening recently (much more recently than the gsd-usb-protection crash), and it goes away if you boot enforcing=0, so it's an SELinux issue.

On that basis, I'd suggest removing this as a blocker candidate, if you think my evaluation is correct.

Note, bug #1937073 is the F34 report for this same crash. https://bugzilla.redhat.com/show_bug.cgi?id=1937108 is a dupe of it which abrt is still filing quite a lot of dupes of.

(In reply to Adam Williamson from comment #16)
 
> On that basis, I'd suggest removing this as a blocker candidate, if you
> think my evaluation is correct.

Thanks Adam, it looks like coincidental timing. I've removed it from blocker consideration.

Similar problem has been detected:

just booted fedora 35 nightly

reporter:       libreport-2.15.2
backtrace_rating: 4
cgroup:         0::/user.slice/user-983.slice/session-c1.scope
cmdline:        /usr/libexec/gsd-usb-protection
crash_function: get_current_screen_saver_status
executable:     /usr/libexec/gsd-usb-protection
journald_cursor: s=c5fd04484f14447b81c8fd0f46c2e35a;i=65b;b=2f81ac60b9b3410086c8753b0d5fe6b9;m=4b795eb;t=5cb2e1b7f233b;x=2a854b7d877d82fa
kernel:         5.14.0-60.fc35.x86_64
package:        gnome-settings-daemon-41~rc-2.fc35
reason:         gsd-usb-protection killed by SIGSEGV
rootdir:        /
runlevel:       unknown
type:           CCpp
uid:            983

*** Bug 2000300 has been marked as a duplicate of this bug. ***

note, proposed F35 Final blocker status is transferred here from dupe 2000300. That bug was based on the probably wrong idea that this crash causes gnome-initial-setup to start slowly, but it *is* possible this crash causes the visible 'sadface' at boot, and that may still happen (albeit briefly) if we fix g-i-s's slow start, which is tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1997310 .

(In reply to Adam Williamson from comment #21)
> note, proposed F35 Final blocker status is transferred here from dupe
> 2000300. That bug was based on the probably wrong idea that this crash
> causes gnome-initial-setup to start slowly, but it *is* possible this crash
> causes the visible 'sadface' at boot, and that may still happen (albeit
> briefly) if we fix g-i-s's slow start, which is tracked at
> https://bugzilla.redhat.com/show_bug.cgi?id=1997310 .

Just a follow up: I opened that bug and proposed it as a blocker because of the sadface, not the slow boot. That particular system boots slow enough that I'm not sure I would notice any slowdown. I do see AVC denials matching those described in 1997310[0]. Booting with enforcing=0 does not prevent the sad face but does not show the gsb-usb-protect crash so that problem must originate elsewhere.

[0] - https://bugzilla.redhat.com/show_bug.cgi?id=1997310

Can we merge this and bug 2003285, are they the same?

#agreed 1950669 -  The decision to delay the classification of this as a blocker bug was made as we are unsure if this is a duplicate of 2003285 at the moment.

(In reply to Kamil Páral from comment #23)
> Can we merge this and bug 2003285, are they the same?

I think they're sort of the same.

Obviously the crash that's occurring is exactly the same, judging by the backtrace, so yes, it would be appropriate to mark bug #2003285 as a duplicate of this issue. (I hesitate to do that myself because that one is AcceptedBlocker, so I'll let blocker/exception people deal with that.)

But my theory is the crash is now happening for some different underlying reason than when this bug was originally reported. I think something more recent -- probably selinux, but I would need to check again to be certain -- is breaking D-Bus in the initial setup environment, and that causes this bug to occur regularly when it would normally occur more rarely. I also think that may be fixed in the latest compose, though I'd need to check that too. So this issue *might* be "fixed" such that we no longer see the fail whale screen in the initial setup session and it is no longer be serious enough to be a blocker, even though the bug is not actually fixed and we're still getting crash reports.

I'm just going to go ahead and dup the issue. I'm not sure if we need to manually move over the AcceptedBlocker status or not.

*** Bug 2003285 has been marked as a duplicate of this bug. ***

(In reply to Michael Catanzaro from comment #25)
> But my theory is the crash is now happening for some different underlying
> reason than when this bug was originally reported.

Benjamin suspects this is bug #1996998, DBUS_SESSION_BUS_ADDRESS gets discarded because gnome-shell has setcap. That theory is consistent with our "everything that uses D-Bus is broken" symptoms so I kinda suspect he is correct. We should check if the update for that bug "fixes" this issue. (Note that there is also a error handling bug in gsb-usb-protection-daemon, which we still need to fix regardless, but this issue no longer needs to be proposed blocker if the fail whale screen is no longer shown during initial setup.)

*** Bug 2004410 has been marked as a duplicate of this bug. ***

Similar problem has been detected:

Happens on boot of cleanly installed system from F35 Workstation live image including gnome-shell-41~rc.1-2.fc35 (with capabilities drop change).

reporter:       libreport-2.15.2
backtrace_rating: 4
cgroup:         0::/user.slice/user-983.slice/session-c1.scope
cmdline:        /usr/libexec/gsd-usb-protection
crash_function: get_current_screen_saver_status
executable:     /usr/libexec/gsd-usb-protection
journald_cursor: s=48d7b9a8ea2144c8980ea0719dc8b4c8;i=63b;b=89af5d394eb248d790e02c12147c5458;m=76f5775;t=5cc0d56edd6dc;x=a920ee17860c734d
kernel:         5.14.0-60.fc35.x86_64
package:        gnome-settings-daemon-41~rc-2.fc35
reason:         gsd-usb-protection killed by SIGSEGV
rootdir:        /
runlevel:       unknown
type:           CCpp
uid:            983

Note, the above comment means this likely isn't 1996998 , because I tested an install from a live image built with https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0b0be7c4e and still got this crash. I still saw a sadface before g-i-s finally ran. I'll attach the full backtrace.

Created attachment 1823418 [details]
backtrace from crash with latest gnome-shell build with extra capabilities dropped

(In reply to Adam Williamson from comment #32)
> Created attachment 1823418 [details]
> backtrace from crash with latest gnome-shell build with extra capabilities
> dropped

That crash is unchanged, unfortunately. Well, no matter, we need to fix it in gsd anyway.

Any chance you still have access to the system journal from right before the crash? Would be good to confirm whether there are critical warnings printing right before it crashes. If so, that would confirm our theory in the upstream bug and it shouldn't be hard to fix.

huh, well, here's a funny thing...if I boot enforcing=0 with this live image, I don't see the sadface, and there's no trace of the crash in the journal. But I think with older gnome-shell, we see the sadface even with enforcing=0. Weird difference.

Anyway, here's some journal context from booting with enforcing on and reproducing the crash:

Sep 15 14:25:46 fedora audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=geoclue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Sep 15 14:25:50 fedora gsd-housekeepin[1087]: Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.Daemon: Timeout was reached (g-io-error-quark, 24)
Sep 15 14:25:50 fedora gsd-sound[1078]: Error creating proxy: Error calling StartServiceByName for org.gtk.vfs.Daemon: Timeout was reached (g-io-error-quark, 24)
Sep 15 14:25:50 fedora gsd-usb-protect[1096]: Failed to connect to the screen saver: Error calling StartServiceByName for org.gnome.ScreenSaver: Timeout was reached
Sep 15 14:25:50 fedora gsd-usb-protect[1096]: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed
Sep 15 14:25:50 fedora kernel: show_signal_msg: 110 callbacks suppressed
Sep 15 14:25:50 fedora kernel: gsd-usb-protect[1096]: segfault at 8 ip 00005579d7b9ac48 sp 00007fffff0c0330 error 4 in gsd-usb-protection[5579d7b98000+4000]

so yeah, right before crash happens, some dbus-y timeouts are logged. And nothing else happened for four seconds before that.

(In reply to Adam Williamson from comment #34)
> huh, well, here's a funny thing...if I boot enforcing=0 with this live
> image, I don't see the sadface, and there's no trace of the crash in the
> journal. But I think with older gnome-shell, we see the sadface even with
> enforcing=0. Weird difference.
> 
[Snip]

I can confirm previously I would see the sadface even with enforcing=0.

(In reply to Adam Williamson from comment #34)
> huh, well, here's a funny thing...if I boot enforcing=0 with this live
> image, I don't see the sadface, and there's no trace of the crash in the
> journal. But I think with older gnome-shell, we see the sadface even with
> enforcing=0. Weird difference.

Could it be that *both* selinux *and* gnome-shell setcap were breaking D-Bus? Now that gnome-shell is fixed, selinux is the only remaining cause?

> Sep 15 14:25:50 fedora gsd-usb-protect[1096]: g_dbus_proxy_call_sync_internal: assertion 'G_IS_DBUS_PROXY (proxy)' failed

Anyway that's excellent to see, because it suggests that Benjamin's theory of what is going on here is correct.

"Could it be that *both* selinux *and* gnome-shell setcap were breaking D-Bus? Now that gnome-shell is fixed, selinux is the only remaining cause?"

that seems possible, yeah. It'll be interesting to see what happens when we get a new selinux policy build.

So potentially the situation is that we could fix g-s-d to not crash *even if stuff goes wrong with dbus*, but we can also avoid the crash happening in practice by just making the dbus stuff work. And that's probably more important because even if we fix g-s-d not to crash in this case, if dbus stuff is going wrong it likely has other consequences like the slow startup, keyboard layout issues, and missing GOA page...

> Could it be that *both* selinux *and* gnome-shell setcap were breaking D-Bus?

Yikes, that sounds very plausible. Maybe there are "gdm" user specific rules and we need something similar for the initial setup user?

> So potentially the situation is that we could fix g-s-d to not crash *even if stuff goes wrong with dbus*, but we can also avoid the crash happening in practice by just making the dbus stuff work.

Yeah, that was the reason why I was kind of refusing to just fix the crash the whole time. Even though fixing the crash itself is trivial.

(In reply to Benjamin Berg from comment #38)
> Yeah, that was the reason why I was kind of refusing to just fix the crash
> the whole time. Even though fixing the crash itself is trivial.

I'm going to propose a MR that should fix this crash upstream.

But I agree we should not rush the fix into downstream. The problems with D-Bus are the more serious blocker issue here. When those are fixed, then we can remove blocker status from this issue without having to actually fix this issue.

So it looks like we were right - we got an SELinux fix this morning, and in an image openQA built with both that fix *and* the latest GNOME bits, we get fast g-i-s and no sadface. I'll verify locally that the crash isn't happening any more, but it sure looks like it isn't.

I tested a 2021-09-19 build and didn't found this happening anymore.

Discussed during the 2021-09-20 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker (Final)" was made as we believe at this point other bugs have been fixed such that this crash will not usually be encountered, and so there is no need for it to be a blocker or FE issue.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-09-20/f35-blocker-review.2021-09-20-16.00.txt

This message is a reminder that Fedora Linux 35 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '35'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 35 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Looks like this was actually resolved long ago and I forgot to close it.