Bug 2071259 - gnome-initial-setup hangs when I try to setup a google/microsoft online account
Summary: gnome-initial-setup hangs when I try to setup a google/microsoft online account
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 36
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F36FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2022-04-02 13:01 UTC by lnie
Modified: 2022-04-26 02:40 UTC (History)
21 users (show)

Fixed In Version: selinux-policy-36.7-1.fc36
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-04-26 02:40:14 UTC
Type: Bug


Attachments (Terms of Use)
screencast (627.44 KB, video/webm)
2022-04-02 13:01 UTC, lnie
no flags Details
journal (991.98 KB, text/plain)
2022-04-02 13:05 UTC, lnie
no flags Details
gstack of g-i-s (12.12 KB, text/plain)
2022-04-11 03:55 UTC, lnie
no flags Details
journal with enforcing=0 (265.08 KB, text/plain)
2022-04-11 13:55 UTC, Kamil Páral
no flags Details
journal with "setenforce 0" (218.82 KB, text/plain)
2022-04-12 03:45 UTC, lnie
no flags Details
journal with enforcing=0 (205.66 KB, text/plain)
2022-04-12 03:47 UTC, lnie
no flags Details
journal from j0328 with default SELinux mode (214.87 KB, text/plain)
2022-04-12 03:50 UTC, lnie
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1151 0 None open Allow xdm mounton user temporary socket files 2022-04-14 14:36:09 UTC

Description lnie 2022-04-02 13:01:15 UTC
Created attachment 1870167 [details]
screencast

Description of problem:
do a default installation with Fedora-Workstation-Live-x86_64-Rawhide-20220401.n.1.iso,try to setup a google/microsoft account during g-i-s,the system seems hangs,though I'm able to switch to tty.I have to reboot the system,and skip that step.

Version-Release number of selected component (if applicable):
gnome-initial-setup-42.0.1-1.fc36.x86_64

How reproducible:
always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 lnie 2022-04-02 13:05:57 UTC
Created attachment 1870168 [details]
journal

Comment 2 Fedora Blocker Bugs Application 2022-04-02 13:14:53 UTC
Proposed as a Blocker for 36-final by Fedora user lnie using the blocker tracking app because:

 This is a violation of the criteria:
If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test.

Comment 3 Lukas Ruzicka 2022-04-04 11:00:17 UTC
I can also reproduce it.

Comment 4 Kamil Páral 2022-04-04 14:33:01 UTC
(In reply to lnie from comment #0)
> Fedora-Workstation-Live-x86_64-Rawhide-20220401.n.1.iso,try to setup a

Hi Lili, just a small technical note, it's better to test with F36 composes in order to file F36 blockers. Rawhide is now separate and differs from F36. But Lukas also verified it, I suppose with a F36 compose, so no action needed :)

Comment 5 Geoffrey Marr 2022-04-04 15:31:16 UTC
Discussed using the asynchronous bug tracking platform: [0]

The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion:

"If an initial setup utility is run or intended to be run after the first boot of the installed system, then it must start successfully and each page or panel of the initial setup utility should withstand a basic functionality test."

[0] https://qa.fedoraproject.org/blockerbugs/

Comment 6 Kamil Páral 2022-04-04 15:36:12 UTC
(In reply to Geoffrey Marr from comment #5)
> [0] https://qa.fedoraproject.org/blockerbugs/

The link should have been: https://pagure.io/fedora-qa/blocker-review/issue/711

Comment 7 lnie 2022-04-06 04:57:48 UTC
(In reply to Kamil Páral from comment #4)
> (In reply to lnie from comment #0)
> > Fedora-Workstation-Live-x86_64-Rawhide-20220401.n.1.iso,try to setup a
> 
> Hi Lili, just a small technical note, it's better to test with F36 composes
> in order to file F36 blockers. Rawhide is now separate and differs from F36.
> But Lukas also verified it, I suppose with a F36 compose, so no action
> needed :)

Hi Kamil,thanks for your note,I know and I mean Fedora-Workstation-Live-x86_64-36-20220401.n.1.iso,sorry for the confuse.

Comment 8 lnie 2022-04-06 05:07:13 UTC
Thanks Lucas for confirming it,Mon and Tue is China state holiday.
Anyway,I found the system installed with workstation iso older than 0329 is not affected by this bug.
0329 and 0328 have the same g-i-s,I created a VM with 0328,and have gnome-session,glib2,gdm,gnome-settings-daemon,xdg-desktop-portal-gnome,gnome-control-center from this page[1] installed before the first boot,
but I didn't see this bug.
[1]https://bodhi.fedoraproject.org/updates/FEDORA-2022-a69718b1e1

Comment 9 Daniel Rusek 2022-04-06 11:56:46 UTC
I can also reproduce the issue on a Fedora 36 installed from a Fedora-Workstation-Live-x86_64-36-20220405.n.0 compose iso.

Comment 10 Debarshi Ray 2022-04-08 18:19:42 UTC
The attached journal entries have this xdg-desktop-portal crash:

Stack trace of thread 4263:
#0  0x000055d3b025fdc9 map_pid_if_needed (xdg-desktop-portal + 0x31dc9)
#1  0x000055d3b0265c6e handle_make_thread_realtime_with_pid (xdg-desktop-portal + 0x37c6e)
#2  0x00007f0b4b9fc746 ffi_call_unix64 (libffi.so.8 + 0x7746)
#3  0x00007f0b4b9f94d2 ffi_call_int.lto_priv.0 (libffi.so.8 + 0x44d2)
#4  0x00007f0b4be0efc3 g_cclosure_marshal_generic (libgobject-2.0.so.0 + 0x19fc3)
#5  0x00007f0b4be08da0 g_closure_invoke (libgobject-2.0.so.0 + 0x13da0)
#6  0x00007f0b4be355e5 signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x405e5)
#7  0x000055d3b028f22b _xdp_realtime_skeleton_handle_method_call (xdg-desktop-portal + 0x6122b)
#8  0x00007f0b4bf77f9b dispatch_in_thread_func (libgio-2.0.so.0 + 0x123f9b)
#9  0x00007f0b4bf06023 g_task_thread_pool_thread (libgio-2.0.so.0 + 0xb2023)
#10 0x00007f0b4bd3ab72 g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x81b72)
#11 0x00007f0b4bd38172 g_thread_proxy (libglib-2.0.so.0 + 0x7f172)
#12 0x00007f0b4bb26017 start_thread (libc.so.6 + 0x91017)
#13 0x00007f0b4bbab6d0 __clone3 (libc.so.6 + 0x1166d0)

... which makes me think that this is a duplicate of bug 2036518.

However, I am not 100% sure.  What's the version of xdg-desktop-portal (ie., rpm -q xdg-desktop-portal) when gnome-initial-setup hangs this way?  If it's not xdg-desktop-portal-1.12.3-1.fc36, then could you please try this update:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-357ef7c464

If that's not the case, could you please try to get a stack trace of the stuck gnome-initial-setup process (ie., gstack <PID-of-stuck-process>) ?

Comment 11 Adam Williamson 2022-04-09 09:18:50 UTC
I'd been figuring the traceback was coincidental, as failure to initialize the portal stuff doesn't seem like it should cause this problem. But I guess it's possible it does somehow.

Comment 12 Debarshi Ray 2022-04-09 20:54:21 UTC
(In reply to Adam Williamson from comment #11)
> I'd been figuring the traceback was coincidental, as failure to initialize
> the portal stuff doesn't seem like it should cause this problem. But I guess
> it's possible it does somehow.

The original report says that gnome-initial-setup hangs while trying to set up Google and Microsoft online accounts. Setting those up need WebKitGTK, and WebKitGTK triggers this particular xdg-desktop-portal crash.

WebKitGTK is also involved in the handling of captive network portals, and those also trigger the same crash.

Comment 13 Debarshi Ray 2022-04-10 16:19:17 UTC
These two RejectedBlocker bugs look similar:
https://bugzilla.redhat.com/show_bug.cgi?id=2054594
https://bugzilla.redhat.com/show_bug.cgi?id=2063673

... and I am even more interested in the xdg-desktop-portal version when this crash is reproduced.

Comment 14 lnie 2022-04-11 03:55:01 UTC
Created attachment 1871698 [details]
gstack of g-i-s

Comment 15 lnie 2022-04-11 03:59:07 UTC
(In reply to Debarshi Ray from comment #10)
> The attached journal entries have this xdg-desktop-portal crash:
> 
> Stack trace of thread 4263:
> #0  0x000055d3b025fdc9 map_pid_if_needed (xdg-desktop-portal + 0x31dc9)
> #1  0x000055d3b0265c6e handle_make_thread_realtime_with_pid
> (xdg-desktop-portal + 0x37c6e)
> #2  0x00007f0b4b9fc746 ffi_call_unix64 (libffi.so.8 + 0x7746)
> #3  0x00007f0b4b9f94d2 ffi_call_int.lto_priv.0 (libffi.so.8 + 0x44d2)
> #4  0x00007f0b4be0efc3 g_cclosure_marshal_generic (libgobject-2.0.so.0 +
> 0x19fc3)
> #5  0x00007f0b4be08da0 g_closure_invoke (libgobject-2.0.so.0 + 0x13da0)
> #6  0x00007f0b4be355e5 signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 +
> 0x405e5)
> #7  0x000055d3b028f22b _xdp_realtime_skeleton_handle_method_call
> (xdg-desktop-portal + 0x6122b)
> #8  0x00007f0b4bf77f9b dispatch_in_thread_func (libgio-2.0.so.0 + 0x123f9b)
> #9  0x00007f0b4bf06023 g_task_thread_pool_thread (libgio-2.0.so.0 + 0xb2023)
> #10 0x00007f0b4bd3ab72 g_thread_pool_thread_proxy.lto_priv.0
> (libglib-2.0.so.0 + 0x81b72)
> #11 0x00007f0b4bd38172 g_thread_proxy (libglib-2.0.so.0 + 0x7f172)
> #12 0x00007f0b4bb26017 start_thread (libc.so.6 + 0x91017)
> #13 0x00007f0b4bbab6d0 __clone3 (libc.so.6 + 0x1166d0)
> 
> ... which makes me think that this is a duplicate of bug 2036518.
> 
> However, I am not 100% sure.  What's the version of xdg-desktop-portal (ie.,
> rpm -q xdg-desktop-portal) when gnome-initial-setup hangs this way?  If it's
> not xdg-desktop-portal-1.12.3-1.fc36, then could you please try this update:
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-357ef7c464
> 
> If that's not the case, could you please try to get a stack trace of the
> stuck gnome-initial-setup process (ie., gstack <PID-of-stuck-process>) ?

That stack trace is from the crash of #bug2054594

I checked with xdg-desktop-portal-1.12.3-1.fc36,the after--g-i-s-crash is gone,but the g-i-s hang is still there,
and the gstack has been attached.

Comment 16 Debarshi Ray 2022-04-11 10:03:59 UTC
This thread in the stack trace looks interesting:

Thread 1 (Thread 0x7f9e4556a540 (LWP 1293) "gnome-initial-s"):
#0  0x00007f9e4b9d6eac in read () from /lib64/libc.so.6
#1  0x00007f9e4c58ada6 in WebKit::XDGDBusProxy::launch(bool) const () from /lib64/libwebkit2gtk-4.0.so.37
#2  0x00007f9e4c58b52b in WebKit::XDGDBusProxy::XDGDBusProxy(WebKit::XDGDBusProxy::Type, bool) () from /lib64/libwebkit2gtk-4.0.so.37
#3  0x00007f9e4c58a11a in WebKit::bubblewrapSpawn(_GSubprocessLauncher*, WebKit::ProcessLauncher::LaunchOptions const&, char**, _GError**) () from /lib64/libwebkit2gtk-4.0.so.37
#4  0x00007f9e4c58a975 in WebKit::ProcessLauncher::launchProcess() () from /lib64/libwebkit2gtk-4.0.so.37
#5  0x00007f9e4c458d4d in WebKit::AuxiliaryProcessProxy::connect() () from /lib64/libwebkit2gtk-4.0.so.37
#6  0x00007f9e4c49a1b2 in WebKit::WebProcessPool::createNewWebProcess(WebKit::WebsiteDataStore*, WebKit::WebProcessProxy::CaptivePortalMode, WebKit::WebProcessProxy::IsPrewarmed, WebCore::CrossOriginMode) () from /lib64/libwebkit2gtk-4.0.so.37
#7  0x00007f9e4c49b104 in WebKit::WebProcessPool::processForRegistrableDomain(WebKit::WebsiteDataStore&, WebCore::RegistrableDomain const&, WebKit::WebProcessProxy::CaptivePortalMode) () from /lib64/libwebkit2gtk-4.0.so.37
#8  0x00007f9e4c49e362 in WebKit::WebPageProxy::launchProcess(WebCore::RegistrableDomain const&, WebKit::WebPageProxy::ProcessLaunchReason) () from /lib64/libwebkit2gtk-4.0.so.37
#9  0x00007f9e4dd5fa04 in WebKit::WebPageProxy::loadRequest(WebCore::ResourceRequest&&, WebCore::ShouldOpenExternalURLsPolicy, API::Object*) [clone .constprop.0] () from /lib64/libwebkit2gtk-4.0.so.37
#10 0x00007f9e4c51c416 in webkit_web_view_load_uri () from /lib64/libwebkit2gtk-4.0.so.37
#11 0x00007f9e4f7ae362 in get_tokens_and_identity () from /lib64/libgoa-backend-1.0.so.1
#12 0x00007f9e4f7ae8bf in goa_oauth2_provider_add_account () from /lib64/libgoa-backend-1.0.so.1
#13 0x00007f9e4f7a00f8 in goa_provider_add_account () from /lib64/libgoa-backend-1.0.so.1
#14 0x000055de4af5eba2 in row_activated ()
#15 0x00007f9e4faef835 in g_cclosure_marshal_VOID__OBJECTv () from /lib64/libgobject-2.0.so.0
#16 0x00007f9e4fb0db59 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#17 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#18 0x00007f9e4f16e534 in gtk_list_box_multipress_gesture_released () from /lib64/libgtk-3.so.0
#19 0x00007f9e4f008125 in _gtk_marshal_VOID__INT_DOUBLE_DOUBLEv () from /lib64/libgtk-3.so.0
#20 0x00007f9e4fb0db59 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#21 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#22 0x00007f9e4f12b634 in gtk_gesture_multi_press_end () from /lib64/libgtk-3.so.0
#23 0x00007f9e4faf57b6 in g_cclosure_marshal_VOID__BOXEDv () from /lib64/libgobject-2.0.so.0
#24 0x00007f9e4fb0db59 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#25 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#26 0x00007f9e4f11d8ab in _gtk_gesture_check_recognized.lto_priv.0 () from /lib64/libgtk-3.so.0
#27 0x00007f9e4f126e33 in gtk_gesture_handle_event () from /lib64/libgtk-3.so.0
#28 0x00007f9e4f12c2e0 in gtk_gesture_single_handle_event () from /lib64/libgtk-3.so.0
#29 0x00007f9e4f0e4bc0 in gtk_event_controller_handle_event () from /lib64/libgtk-3.so.0
#30 0x00007f9e4f2dccb5 in _gtk_widget_run_controllers.lto_priv.0 () from /lib64/libgtk-3.so.0
#31 0x00007f9e4f0067f8 in _gtk_marshal_BOOLEAN__BOXEDv () from /lib64/libgtk-3.so.0
#32 0x00007f9e4fb0db59 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#33 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#34 0x00007f9e4f2ec664 in gtk_widget_event_internal.part.0.lto_priv () from /lib64/libgtk-3.so.0
#35 0x00007f9e4f177f00 in propagate_event.lto_priv () from /lib64/libgtk-3.so.0
#36 0x00007f9e4f178cea in gtk_main_do_event () from /lib64/libgtk-3.so.0
#37 0x00007f9e4eea5523 in _gdk_event_emit () from /lib64/libgdk-3.so.0
#38 0x00007f9e4eed7db6 in gdk_event_source_dispatch () from /lib64/libgdk-3.so.0
#39 0x00007f9e4f9f5f4f in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#40 0x00007f9e4fa4b168 in g_main_context_iterate.constprop () from /lib64/libglib-2.0.so.0
#41 0x00007f9e4f9f38e0 in g_main_context_iteration () from /lib64/libglib-2.0.so.0
#42 0x00007f9e4fc1c27d in g_application_run () from /lib64/libgio-2.0.so.0
#43 0x000055de4af3a138 in main ()

Frames #1 and #2 hint at some xdg-dbus-proxy and xdg-desktop-portal activity, and #3 is about Bubblewrap.

I have seen Bubblewrap and Flatpak butt heads with SELinux recently.  Do you still see the crash if you have SELinux set in 'permissive' mode?  I don't know how to do that easily for the live installer.  :/

How did you check with xdg-desktop-portal-1.12.3-1.fc36?  Was that RPM already part of the ISO, or did you install it separately?  In case of the latter, did you at least restart or log out of your GNOME session before trying again?

Comment 17 lnie 2022-04-11 10:21:39 UTC
(In reply to Debarshi Ray from comment #16)
> This thread in the stack trace looks interesting:
> 
> Thread 1 (Thread 0x7f9e4556a540 (LWP 1293) "gnome-initial-s"):
> #0  0x00007f9e4b9d6eac in read () from /lib64/libc.so.6
> #1  0x00007f9e4c58ada6 in WebKit::XDGDBusProxy::launch(bool) const () from
> /lib64/libwebkit2gtk-4.0.so.37
> #2  0x00007f9e4c58b52b in
> WebKit::XDGDBusProxy::XDGDBusProxy(WebKit::XDGDBusProxy::Type, bool) () from
> /lib64/libwebkit2gtk-4.0.so.37
> #3  0x00007f9e4c58a11a in WebKit::bubblewrapSpawn(_GSubprocessLauncher*,
> WebKit::ProcessLauncher::LaunchOptions const&, char**, _GError**) () from
> /lib64/libwebkit2gtk-4.0.so.37
> #4  0x00007f9e4c58a975 in WebKit::ProcessLauncher::launchProcess() () from
> /lib64/libwebkit2gtk-4.0.so.37
> #5  0x00007f9e4c458d4d in WebKit::AuxiliaryProcessProxy::connect() () from
> /lib64/libwebkit2gtk-4.0.so.37
> #6  0x00007f9e4c49a1b2 in
> WebKit::WebProcessPool::createNewWebProcess(WebKit::WebsiteDataStore*,
> WebKit::WebProcessProxy::CaptivePortalMode,
> WebKit::WebProcessProxy::IsPrewarmed, WebCore::CrossOriginMode) () from
> /lib64/libwebkit2gtk-4.0.so.37
> #7  0x00007f9e4c49b104 in
> WebKit::WebProcessPool::processForRegistrableDomain(WebKit::
> WebsiteDataStore&, WebCore::RegistrableDomain const&,
> WebKit::WebProcessProxy::CaptivePortalMode) () from
> /lib64/libwebkit2gtk-4.0.so.37
> #8  0x00007f9e4c49e362 in
> WebKit::WebPageProxy::launchProcess(WebCore::RegistrableDomain const&,
> WebKit::WebPageProxy::ProcessLaunchReason) () from
> /lib64/libwebkit2gtk-4.0.so.37
> #9  0x00007f9e4dd5fa04 in
> WebKit::WebPageProxy::loadRequest(WebCore::ResourceRequest&&,
> WebCore::ShouldOpenExternalURLsPolicy, API::Object*) [clone .constprop.0] ()
> from /lib64/libwebkit2gtk-4.0.so.37
> #10 0x00007f9e4c51c416 in webkit_web_view_load_uri () from
> /lib64/libwebkit2gtk-4.0.so.37
> #11 0x00007f9e4f7ae362 in get_tokens_and_identity () from
> /lib64/libgoa-backend-1.0.so.1
> #12 0x00007f9e4f7ae8bf in goa_oauth2_provider_add_account () from
> /lib64/libgoa-backend-1.0.so.1
> #13 0x00007f9e4f7a00f8 in goa_provider_add_account () from
> /lib64/libgoa-backend-1.0.so.1
> #14 0x000055de4af5eba2 in row_activated ()
> #15 0x00007f9e4faef835 in g_cclosure_marshal_VOID__OBJECTv () from
> /lib64/libgobject-2.0.so.0
> #16 0x00007f9e4fb0db59 in g_signal_emit_valist () from
> /lib64/libgobject-2.0.so.0
> #17 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> #18 0x00007f9e4f16e534 in gtk_list_box_multipress_gesture_released () from
> /lib64/libgtk-3.so.0
> #19 0x00007f9e4f008125 in _gtk_marshal_VOID__INT_DOUBLE_DOUBLEv () from
> /lib64/libgtk-3.so.0
> #20 0x00007f9e4fb0db59 in g_signal_emit_valist () from
> /lib64/libgobject-2.0.so.0
> #21 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> #22 0x00007f9e4f12b634 in gtk_gesture_multi_press_end () from
> /lib64/libgtk-3.so.0
> #23 0x00007f9e4faf57b6 in g_cclosure_marshal_VOID__BOXEDv () from
> /lib64/libgobject-2.0.so.0
> #24 0x00007f9e4fb0db59 in g_signal_emit_valist () from
> /lib64/libgobject-2.0.so.0
> #25 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> #26 0x00007f9e4f11d8ab in _gtk_gesture_check_recognized.lto_priv.0 () from
> /lib64/libgtk-3.so.0
> #27 0x00007f9e4f126e33 in gtk_gesture_handle_event () from
> /lib64/libgtk-3.so.0
> #28 0x00007f9e4f12c2e0 in gtk_gesture_single_handle_event () from
> /lib64/libgtk-3.so.0
> #29 0x00007f9e4f0e4bc0 in gtk_event_controller_handle_event () from
> /lib64/libgtk-3.so.0
> #30 0x00007f9e4f2dccb5 in _gtk_widget_run_controllers.lto_priv.0 () from
> /lib64/libgtk-3.so.0
> #31 0x00007f9e4f0067f8 in _gtk_marshal_BOOLEAN__BOXEDv () from
> /lib64/libgtk-3.so.0
> #32 0x00007f9e4fb0db59 in g_signal_emit_valist () from
> /lib64/libgobject-2.0.so.0
> #33 0x00007f9e4fb0dc93 in g_signal_emit () from /lib64/libgobject-2.0.so.0
> #34 0x00007f9e4f2ec664 in gtk_widget_event_internal.part.0.lto_priv () from
> /lib64/libgtk-3.so.0
> #35 0x00007f9e4f177f00 in propagate_event.lto_priv () from
> /lib64/libgtk-3.so.0
> #36 0x00007f9e4f178cea in gtk_main_do_event () from /lib64/libgtk-3.so.0
> #37 0x00007f9e4eea5523 in _gdk_event_emit () from /lib64/libgdk-3.so.0
> #38 0x00007f9e4eed7db6 in gdk_event_source_dispatch () from
> /lib64/libgdk-3.so.0
> #39 0x00007f9e4f9f5f4f in g_main_context_dispatch () from
> /lib64/libglib-2.0.so.0
> #40 0x00007f9e4fa4b168 in g_main_context_iterate.constprop () from
> /lib64/libglib-2.0.so.0
> #41 0x00007f9e4f9f38e0 in g_main_context_iteration () from
> /lib64/libglib-2.0.so.0
> #42 0x00007f9e4fc1c27d in g_application_run () from /lib64/libgio-2.0.so.0
> #43 0x000055de4af3a138 in main ()
> 
> Frames #1 and #2 hint at some xdg-dbus-proxy and xdg-desktop-portal
> activity, and #3 is about Bubblewrap.
> 
> I have seen Bubblewrap and Flatpak butt heads with SELinux recently.  Do you
> still see the crash if you have SELinux set in 'permissive' mode?  I don't
> know how to do that easily for the live installer.  :/

I guess what you mean is the hang?

After set SELinux to 'permissive' mode,the hang is gone.


> 
> How did you check with xdg-desktop-portal-1.12.3-1.fc36?  Was that RPM
> already part of the ISO, or did you install it separately?  In case of the
> latter, did you at least restart or log out of your GNOME session before
> trying again?

I do a default install with Fedora-Workstation-Live-x86_64-36-20220405.n.0.iso,which contains xdg-desktop-portal-1.12.3-1.fc36

Comment 18 lnie 2022-04-11 11:43:58 UTC
0328 and 0329(and 0405) contains the same bubblewrap,0328 contains systemd-250.3-6.fc36 and flatpak-1.12.6-1.fc36,while 0329 contains systemd-250.3-8.fc36 and flatpak-1.12.7-1.fc36,I perform a default installation with Fedora-Workstation-Live-x86_64-36-20220328.n.0.iso,and have systemd and flatpak updated before the first boot,but I'm unable to reproduce the hang.

> I have seen Bubblewrap and Flatpak butt heads with SELinux recently.  Do you
> still see the crash if you have SELinux set in 'permissive' mode?  I don't
> know how to do that easily for the live installer.  :/

I boot the installed system and log root on tty,and then "setenforce 0"

Comment 19 Debarshi Ray 2022-04-11 11:50:30 UTC
(In reply to lnie from comment #17)
> (In reply to Debarshi Ray from comment #16)
> > 
> > I have seen Bubblewrap and Flatpak butt heads with SELinux recently.  Do you
> > still see the crash if you have SELinux set in 'permissive' mode?  I don't
> > know how to do that easily for the live installer.  :/
> 
> I guess what you mean is the hang?

Oops, sorry!  Yes, I meant the hang.

> After set SELinux to 'permissive' mode,the hang is gone.

I see.

> > How did you check with xdg-desktop-portal-1.12.3-1.fc36?  Was that RPM
> > already part of the ISO, or did you install it separately?  In case of the
> > latter, did you at least restart or log out of your GNOME session before
> > trying again?
> 
> I do a default install with
> Fedora-Workstation-Live-x86_64-36-20220405.n.0.iso,which contains
> xdg-desktop-portal-1.12.3-1.fc36

I see.

Comment 20 Debarshi Ray 2022-04-11 11:57:08 UTC
Do you see any SELinux denials on the system?

I have seen a few reports of Flatpak and Bubblewrap running into problems with SELinux on Fedora 36, but it will help to know what's exactly happening here.

Comment 21 Kamil Páral 2022-04-11 13:55:29 UTC
Created attachment 1871812 [details]
journal with enforcing=0

Debarshi, this is the system journal after installing Fedora-Workstation-Live-x86_64-36-20220410.n.0.iso and booting it with enforcing=0. I clicked through all online accounts options in the initial setup, but didn't log in to any of those, just opened the dialogs (worked fine, in permissive mode) and closed them.

I see there:
Apr 11 15:51:04 localhost-live audit[1531]: AVC avc:  denied  { mounton } for  pid=1531 comm="bwrap" path="/newroot/run/user/985/at-spi/bus" dev="tmpfs" ino=54 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1

Comment 22 lnie 2022-04-12 03:43:09 UTC
 Setting up a google/microsoft online account will end up with connection timeout when booting with enforcing=0.

 You will be able to setup  online account successfully by running 'setenforce 0' on tty before the online account step.

 I see same AVC denial in both logs.
 
 Actually,you will not to be able to setup online account successfully either on system installed with 0328, 
 you will see the same connection timeout whether in permissive mode or not.

Comment 23 lnie 2022-04-12 03:45:15 UTC
Created attachment 1871889 [details]
journal with  "setenforce 0"

Comment 24 lnie 2022-04-12 03:47:44 UTC
Created attachment 1871890 [details]
journal  with enforcing=0

Comment 25 lnie 2022-04-12 03:50:33 UTC
Created attachment 1871891 [details]
journal from j0328 with default SELinux mode

Comment 26 Kamil Páral 2022-04-12 07:33:36 UTC
(In reply to lnie from comment #22)
>  Setting up a google/microsoft online account will end up with connection
> timeout when booting with enforcing=0.

I tested again and I can connect a google account just fine, when I boot with enforcing=0. I used Fedora-Workstation-Live-x86_64-36-20220410.n.0.iso. Can you try again with that iso or newer?

(`enforcing=0` should be the same as `setenforce 0`. We might have a bigger problem elsewhere if they differ.)

>  You will be able to setup  online account successfully by running
> 'setenforce 0' on tty before the online account step.

If you install a Live image, there should no user available until after you finish gnome-initial-setup. So how exactly have you achieved that you can log in on tty2 before it?

Comment 27 lnie 2022-04-12 09:04:59 UTC
(In reply to Kamil Páral from comment #26)
> (In reply to lnie from comment #22)
> >  Setting up a google/microsoft online account will end up with connection
> > timeout when booting with enforcing=0.
> 
> I tested again and I can connect a google account just fine, when I boot
> with enforcing=0. I used Fedora-Workstation-Live-x86_64-36-20220410.n.0.iso.
> Can you try again with that iso or newer?


> 
> (`enforcing=0` should be the same as `setenforce 0`. We might have a bigger
> problem elsewhere if they differ.)

  Yes,I thought they should be the same ,that's why I run "setenforce 0"
  instead boot with enforcing=0,I need to log root to check journal either way.
  But after saw your last comment,I tried with enforcing=0,and found they behaved differently.
  Er,but just checked again,turns out google account can be set successfully with enforcing=0 occasionally,
  on a fresh installed system,it didn't work the first three times.But it works everytime with "setenforce 0".
  Can you checked on a fresh installed system with "setenforce 0" please?If it worked for you every time,
  then it might be a unstable network issue on my side,though ping works fine everytime.
 
> 
> If you install a Live image, there should no user available until after you
> finish gnome-initial-setup. So how exactly have you achieved that you can
> log in on tty2 before it?

  To be specific, no non-root user available,as I said in #comment18,I log root on tty.

Comment 28 Kamil Páral 2022-04-12 10:10:35 UTC
> then it might be a unstable network issue on my side

Yes, if it worked at least once for you, then you're most probably seeing network issues.

> To be specific, no non-root user available,as I said in #comment18,I log root on tty.

But root is locked by default after a Live install, you can't log in with it. I verified that again just now, there is no change, root is locked. So how exactly are you testing this, can you list each step in detail?

Comment 29 lnie 2022-04-12 10:41:51 UTC
(In reply to Kamil Páral from comment #28)
> > then it might be a unstable network issue on my side
> 
> Yes, if it worked at least once for you, then you're most probably seeing
> network issues.

  Okay,we can ignore the timeout issue then,though I checked "enforcing 0"
  and "setenforce 0" on two different VM hosted on the same machine within 5 minutes,
  and I checked 3 times each way this morning after that.  
   
> 
> > To be specific, no non-root user available,as I said in #comment18,I log root on tty.
> 
> But root is locked by default after a Live install, you can't log in with
> it. I verified that again just now, there is no change, root is locked. So
> how exactly are you testing this, can you list each step in detail?

 yes, I do some magic:perform an installation with 0410, after it is completed,
 chroot to the newly installed system and run "passwd" to set your root password before reboot the system,
 then~~,you will be able to log root on tty without g-i-s.

Comment 30 Kamil Páral 2022-04-12 11:24:18 UTC
(In reply to lnie from comment #29)
>  yes, I do some magic:perform an installation with 0410, after it is
> completed,
>  chroot to the newly installed system and run "passwd" to set your root
> password before reboot the system,
>  then~~,you will be able to log root on tty without g-i-s.

Ok, that was the missing piece, then. Just please be aware that you can introduce selinux-related issues when you chroot into the installed system. It doesn't seem to be the case here, but it's good to be aware of it.

Comment 31 lnie 2022-04-12 13:16:21 UTC
(In reply to Kamil Páral from comment #30)
> (In reply to lnie from comment #29)
> >  yes, I do some magic:perform an installation with 0410, after it is
> > completed,
> >  chroot to the newly installed system and run "passwd" to set your root
> > password before reboot the system,
> >  then~~,you will be able to log root on tty without g-i-s.
> 
> Ok, that was the missing piece, then. Just please be aware that you can
> introduce selinux-related issues when you chroot into the installed system.
> It doesn't seem to be the case here, but it's good to be aware of it.

Er,a little awkward,I wasn't aware that,and I was wondering 
how could you don't notice that magic,anyway,thanks for your info.

Comment 32 Debarshi Ray 2022-04-12 19:10:55 UTC
(In reply to Kamil Páral from comment #21)
> Created attachment 1871812 [details]
> journal with enforcing=0
> 
> Debarshi, this is the system journal after installing
> Fedora-Workstation-Live-x86_64-36-20220410.n.0.iso and booting it with
> enforcing=0. I clicked through all online accounts options in the initial
> setup, but didn't log in to any of those, just opened the dialogs (worked
> fine, in permissive mode) and closed them.
> 
> I see there:
> Apr 11 15:51:04 localhost-live audit[1531]: AVC avc:  denied  { mounton }
> for  pid=1531 comm="bwrap" path="/newroot/run/user/985/at-spi/bus"
> dev="tmpfs" ino=54 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023
> tcontext=system_u:object_r:user_tmp_t:s0 tclass=sock_file permissive=1

Hey Zdeněk!  Could you please tell me how to supress this SELinux denial?  This looks a lot like bug 2073566

Comment 33 Zdenek Pytela 2022-04-14 14:36:10 UTC
This one needs to be addressed in selinux-policy.

Comment 34 Ben Cotton 2022-04-18 16:19:26 UTC
Changing component to reflect comment 33. It would be very good if we can get a build today that includes this, as the Go/No-Go meeting is Thursday.

Comment 35 Fedora Update System 2022-04-21 14:14:24 UTC
FEDORA-2022-76963fee71 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-76963fee71

Comment 36 Kamil Páral 2022-04-21 14:42:14 UTC
(In reply to Fedora Update System from comment #35)
> FEDORA-2022-76963fee71 has been submitted as an update to Fedora 36.
> https://bodhi.fedoraproject.org/updates/FEDORA-2022-76963fee71

Hmm, I tried my own Workstation Live with selinux-policy-36.7-1.fc36 included, so that I can easily test whether gnome-initial-setup is fixed. However, that Live image doesn't even boot to GNOME. I have to boot it with enforcing=0, in which case it boots and the journal contains:

Apr 21 10:36:46 localhost-live audit[1333]: AVC avc:  denied  { transition } for  pid=1333 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-0" ino=25387 scontext=system_u:system_r:kernel_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0 tclass=process permissive=1
Apr 21 10:36:46 localhost-live audit[1333]: AVC avc:  denied  { entrypoint } for  pid=1333 comm="(systemd)" path="/usr/lib/systemd/systemd" dev="dm-0" ino=25387 scontext=unconfined_u:unconfined_r:unconfined_t:s0 tcontext=unconfined_u:object_r:lib_t:s0 tclass=file permissive=1

I wonder if this is a regression in selinux-policy? It can also be a problem in how I built the image, though.

Comment 37 Zdenek Pytela 2022-04-21 15:05:49 UTC
We remove rules from policy very rarely. It looks like a mislabeled file, systemd seems to be running in the kernel_t domain. Consider relabeling of the system, before that you can run

  # restorecon -Rvn /

to see which files have incorrect labels. Note this command can take a long time.

Comment 38 Adam Williamson 2022-04-21 15:58:02 UTC
openQA does a test which builds a live image then boots it, and that worked fine on the update, so it's probably how you built your image, Kamil (I think selinux should be in permissive mode when building images). You can try with the ISO from openQA staging:

https://openqa.stg.fedoraproject.org/tests/1718605/asset/iso/01718605-Fedora-Workstation-Live-x86_64-FEDORA-2022-76963fee71.iso

Comment 39 Martin Wolf 2022-04-21 16:40:04 UTC
I installed it and I do not observe these issues.

Comment 40 Fedora Update System 2022-04-21 17:50:20 UTC
FEDORA-2022-76963fee71 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-76963fee71`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-76963fee71

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 41 lnie 2022-04-22 02:55:18 UTC
Checked with the openqa iso, google/microsoft online account is setup successfully without any issue

Comment 42 Kamil Páral 2022-04-22 06:41:30 UTC
(In reply to Adam Williamson from comment #38)
> (I think selinux should be in permissive mode when building images). 

Thanks, Adam. That was the issue. Sorry about a false alarm.

Comment 43 Fedora Update System 2022-04-26 02:40:14 UTC
FEDORA-2022-76963fee71 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.