Bug 2071259
| Summary: | gnome-initial-setup hangs when I try to setup a google/microsoft online account | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | lnie <lnie> | ||||||||||||||||
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | ||||||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||
| Severity: | medium | Docs Contact: | |||||||||||||||||
| Priority: | medium | ||||||||||||||||||
| Version: | 36 | CC: | awilliam, bcotton, debarshir, drusek, dwalsh, gmarr, gnome-sig, grepl.miroslav, jstpierr, kparal, lruzicka, lvrabec, mail, mmalik, mwolf, omosnace, pkoncity, robatino, tiagomatos, vmojzis, zpytela | ||||||||||||||||
| Target Milestone: | --- | Keywords: | Triaged | ||||||||||||||||
| Target Release: | --- | ||||||||||||||||||
| Hardware: | Unspecified | ||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||
| Whiteboard: | AcceptedBlocker | ||||||||||||||||||
| Fixed In Version: | selinux-policy-36.7-1.fc36 | Doc Type: | If docs needed, set a value | ||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||
| Last Closed: | 2022-04-26 02:40:14 UTC | Type: | Bug | ||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||
| Embargoed: | |||||||||||||||||||
| Bug Depends On: | |||||||||||||||||||
| Bug Blocks: | 1953785 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
Created attachment 1870168 [details]
journal
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. I can also reproduce it. (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 :) 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/ (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 (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. 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 I can also reproduce the issue on a Fedora 36 installed from a Fedora-Workstation-Live-x86_64-36-20220405.n.0 compose iso. 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>) ? 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. (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. 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. Created attachment 1871698 [details]
gstack of g-i-s
(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. 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? (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 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"
(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. 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. 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
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. Created attachment 1871889 [details]
journal with "setenforce 0"
Created attachment 1871890 [details]
journal with enforcing=0
Created attachment 1871891 [details]
journal from j0328 with default SELinux mode
(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? (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. > 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? (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. (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. (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. (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 This one needs to be addressed in selinux-policy. 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. FEDORA-2022-76963fee71 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-76963fee71 (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. 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. 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 I installed it and I do not observe these issues. 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. Checked with the openqa iso, google/microsoft online account is setup successfully without any issue (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. 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. |
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: