Description of problem: After applying all the latest updates through the GNOME Software Center and rebooting into the latest kernel (at the time of writing this, 5.12.6), the dbus-broker-launch fails and systemd will not complete the boot. Version-Release number of selected component (if applicable): Latest version of Fedora 34 Workstation, with the latest applicable updates on 26 May 2021, on a Lenovo Thinkpad T580 20L9CTO1WW How reproducible: Install a fresh copy of Fedora 34 Workstation, then apply all the available updates through GNOME Software and ckick the "Reboot and Install" button. Actual results: After installing the update, the system won't boot and remains stuck at "Showing Plymouth Terminate screen...", after showing the failed DBus initialization and all its dependencies. Expected results: The system boots into the updated kernel. Additional info: I chose to install using LVM over LUKS2, through the settings offered by Anaconda. Enabling persistent journal and looking at the log for dbus-broker service from the failed boot (I am still able to boot the 5.11.12 kernel that Fedora 34 Workstation is packaged with at the moment) I can see the following: -- Journal begins at Wed 2021-05-26 10:40:46 CEST, ends at Wed 2021-05-26 10:45:27 CEST. -- mag 26 10:40:47 thinker systemd[1]: Starting D-Bus System Message Bus... ░░ Subject: A start job for unit dbus-broker.service has begun execution ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit dbus-broker.service has begun execution. ░░ ░░ The job identifier is 77. mag 26 10:40:47 thinker systemd[1]: Started D-Bus System Message Bus. ░░ Subject: A start job for unit dbus-broker.service has finished successfully ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit dbus-broker.service has finished successfully. ░░ ░░ The job identifier is 77. mag 26 10:40:47 thinker dbus-broker-lau[550]: Ready mag 26 10:42:33 thinker systemd[1]: Starting D-Bus System Message Bus... ░░ Subject: A start job for unit dbus-broker.service has begun execution ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit dbus-broker.service has begun execution. ░░ ░░ The job identifier is 407. mag 26 10:42:33 thinker dbus-broker-launch[1314]: Non unix-domain-socket passed as listener mag 26 10:42:33 thinker systemd[1]: dbus-broker.service: Main process exited, code=exited, status=1/FAILURE ░░ Subject: Unit process exited ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ An ExecStart= process belonging to unit dbus-broker.service has exited. ░░ ░░ The process' exit code is 'exited' and its exit status is 1. mag 26 10:42:33 thinker systemd[1]: dbus-broker.service: Failed with result 'exit-code'. ░░ Subject: Unit failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ The unit dbus-broker.service has entered the 'failed' state with result 'exit-code'. mag 26 10:42:33 thinker systemd[1]: Failed to start D-Bus System Message Bus. ░░ Subject: A start job for unit dbus-broker.service has failed ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ ░░ A start job for unit dbus-broker.service has finished with a failure. ░░ ░░ The job identifier is 407 and the job result is failed. I tried to search the manpages and on the web for some insight on that particular message "Non unix-domain-socket passed as listener", but I could not find any useful information to further investigate. Thanks in advance for investing your time and looking into this.
I think this is a duplicate of #1963979. Can we move discussion there? *** This bug has been marked as a duplicate of bug 1963979 ***
(Did not realize the other bug was marked private. I will redirect discussion here.) Can you confirm this bug also happens with selinux disabled?
*** Bug 1963979 has been marked as a duplicate of this bug. ***
I tryed as you suggested: I turned off SELinux by adding selinux=0 to the Linux cmdline in the GRUB entry for Fedora 34 on Linux 5.12.6, and after a long wait on the "Switch Root" steèp, the OS managed to boot. However, the gnome shell crashed, apparently because of XWayland; I tried to use the system a little bit, and I found that at least the new GNOME 40 touchpad gestures are not working. The following is the new lines of logs, with respect to booting with SELinux enabled (by the way: the dbus-broker did not fail this time): mag 26 18:24:51 thinker gnome-shell[2267]: Failed to start X Wayland: Directory "/tmp/.X11-unix" is not writable mag 26 18:24:52 thinker systemd-coredump[2326]: [🡕] Process 2267 (gnome-shell) of user 42 dumped core. Stack trace of thread 2267: #0 0x00007f732e41df7f g_log_structured_array (libglib-2.0.so.0 + 0x5bf7f) #1 0x00007f732e41e249 g_log_default_handler (libglib-2.0.so.0 + 0x5c249) #2 0x00007f732e41f61a g_logv (libglib-2.0.so.0 + 0x5d61a) #3 0x00007f732e41f903 g_log (libglib-2.0.so.0 + 0x5d903) #4 0x00007f732d87a128 meta_wayland_compositor_setup (libmutter-8.so.0 + 0x123128) #5 0x00007f732d7ca172 meta_backend_initable_init (libmutter-8.so.0 + 0x73172) #6 0x00007f732d820907 meta_init (libmutter-8.so.0 + 0xc9907) #7 0x0000561a029359c0 main (gnome-shell + 0x29c0) #8 0x00007f732d5adb75 __libc_start_main (libc.so.6 + 0x27b75) #9 0x0000561a02935ebe _start (gnome-shell + 0x2ebe) Stack trace of thread 2316: #0 0x00007f732cc30a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f732cc2a2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f731431509b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x00007f7314314b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2318: #0 0x00007f732cc30a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f732cc2a2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f731431509b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x00007f7314314b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2299: #0 0x00007f732d67b5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f732e46b47c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa947c) #2 0x00007f732e414c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f732e414c51 glib_worker_main (libglib-2.0.so.0 + 0x52c51) #4 0x00007f732e445c32 g_thread_proxy (libglib-2.0.so.0 + 0x83c32) #5 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2317: #0 0x00007f732cc30a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f732cc2a2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f731431509b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x00007f7314314b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2324: #0 0x00007f732d67b5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f732e46b47c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa947c) #2 0x00007f732e416a93 g_main_loop_run (libglib-2.0.so.0 + 0x54a93) #3 0x00007f732d8bc431 input_thread (libmutter-8.so.0 + 0x165431) #4 0x00007f732e445c32 g_thread_proxy (libglib-2.0.so.0 + 0x83c32) #5 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2311: #0 0x00007f732d67b5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f732e46b47c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa947c) #2 0x00007f732e414c03 g_main_context_iteration (libglib-2.0.so.0 + 0x52c03) #3 0x00007f73283c43ed dconf_gdbus_worker_thread (libdconfsettings.so + 0x73ed) #4 0x00007f732e445c32 g_thread_proxy (libglib-2.0.so.0 + 0x83c32) #5 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2309: #0 0x00007f732d67b5bf __poll (libc.so.6 + 0xf55bf) #1 0x00007f732e46b47c g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa947c) #2 0x00007f732e416a93 g_main_loop_run (libglib-2.0.so.0 + 0x54a93) #3 0x00007f732e667d5a gdbus_shared_thread_func.lto_priv.0 (libgio-2.0.so.0 + 0x110d5a) #4 0x00007f732e445c32 g_thread_proxy (libglib-2.0.so.0 + 0x83c32) #5 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2320: #0 0x00007f732cc30a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f732cc2a2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f731431509b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x00007f7314314b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2319: #0 0x00007f732cc30a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f732cc2a2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f731431509b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x00007f7314314b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2321: #0 0x00007f732d680e0d syscall (libc.so.6 + 0xfae0d) #1 0x00007f732e46584c g_cond_wait_until (libglib-2.0.so.0 + 0xa384c) #2 0x00007f732e3e7401 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x25401) #3 0x00007f732e448c7a g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x86c7a) #4 0x00007f732e445c32 g_thread_proxy (libglib-2.0.so.0 + 0x83c32) #5 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2323: #0 0x00007f732cc30a8a __futex_abstimed_wait_common64 (libpthread.so.0 + 0x15a8a) #1 0x00007f732cc2a2c0 pthread_cond_wait (libpthread.so.0 + 0xf2c0) #2 0x00007f731431509b util_queue_thread_func (iris_dri.so + 0x1b809b) #3 0x00007f7314314b5b impl_thrd_routine (iris_dri.so + 0x1b7b5b) #4 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #5 0x00007f732d686353 __clone (libc.so.6 + 0x100353) Stack trace of thread 2308: #0 0x00007f732d680e0d syscall (libc.so.6 + 0xfae0d) #1 0x00007f732e46584c g_cond_wait_until (libglib-2.0.so.0 + 0xa384c) #2 0x00007f732e3e7401 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x25401) #3 0x00007f732e448c7a g_thread_pool_thread_proxy.lto_priv.0 (libglib-2.0.so.0 + 0x86c7a) #4 0x00007f732e445c32 g_thread_proxy (libglib-2.0.so.0 + 0x83c32) #5 0x00007f732cc24299 start_thread (libpthread.so.0 + 0x9299) #6 0x00007f732d686353 __clone (libc.so.6 + 0x100353) ░░ Subject: Process 2267 (gnome-shell) dumped core ░░ Defined-By: systemd ░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel ░░ Documentation: man:core(5) ░░ ░░ Process 2267 (gnome-shell) crashed and dumped core. ░░ ░░ This usually indicates a programming error in the crashing program and ░░ should be reported to its vendor as a bug. mag 26 18:24:52 thinker gnome-session-binary[2239]: Unrecoverable failure in required component org.gnome.Shell.desktop mag 26 18:24:54 thinker abrt-notification[2661]: [🡕] Process 2267 (gnome-shell) crashed in meta_wayland_compositor_setup() ░░ Subject: ABRT has detected unexpected termination: gnome-shell ░░ Defined-By: ABRT ░░ Support: https://bugzilla.redhat.com/ ░░ Documentation: man:abrt(1) ░░ ░░ gnome-shell killed by SIGTRAP ░░ ░░ #1 [libmutter-8.so.0] meta_wayland_compositor_setup ░░ #2 [libmutter-8.so.0] meta_backend_initable_init ░░ #3 [libmutter-8.so.0] meta_init ░░ #4 [gnome-shell] main ░░ ░░ Use the abrt command-line tool for further analysis or to report ░░ the problem to the appropriate support site.
This is all weird. First of all, if a stable-kernel update causes selinux issues _without_ any AVC logs, and then causes other random processes to dump core, I really assume this is a kernel issue. Can you downgrade your kernel? Does this still happen <=5.12.4?
I tried also to boot kernels 5.11.17 and 5.11.20, and I had no problem there; the exact same issue I described in my first message appears since kernel 5.11.21 (I also tried 5.12.5, which also shows the same issue).
Similar issue. Using kernal and selinux packages from update-testing seems to have helped. > sudo dnf upgrade --enablerepo=updates-testing kernel* selinux* The following packages are now installed and boot succeeds. > kernel-core-5.12.7-300.fc34.x86_64 > kernel-modules-5.12.7-300.fc34.x86_64 > kernel-modules-extra-5.12.7-300.fc34.x86_64 > kernel-devel-5.12.7-300.fc34.x86_64 > kernel-debug-devel-5.12.7-300.fc34.x86_64 > selinux-policy-34.9-1.fc34.noarch > selinux-policy-minimum-34.9-1.fc34.noarch > selinux-policy-targeted-34.9-1.fc34.noarch
(In reply to Arun Babu Neelicattu from comment #7) > Similar issue. Using kernal and selinux packages from update-testing seems > to have helped. > > > sudo dnf upgrade --enablerepo=updates-testing kernel* selinux* > > The following packages are now installed and boot succeeds. > > > kernel-core-5.12.7-300.fc34.x86_64 > > kernel-modules-5.12.7-300.fc34.x86_64 > > kernel-modules-extra-5.12.7-300.fc34.x86_64 > > kernel-devel-5.12.7-300.fc34.x86_64 > > kernel-debug-devel-5.12.7-300.fc34.x86_64 > > selinux-policy-34.9-1.fc34.noarch > > selinux-policy-minimum-34.9-1.fc34.noarch > > selinux-policy-targeted-34.9-1.fc34.noarch In terms of my machine, the it still hangs at "Switching Root" stage. Version: kernel-5.12.7-300.fc34.x86_64 selinux-policy-34.9-1.fc34.noarch If I set "enforcing=0" to the cmdline of kernel-5.12.7-300.fc34.x86_64. It will work around this problem. The selinux denies messages from this issue: May 30 00:07:15 localhost setroubleshoot[8535]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l b8ec7109-2643-448e-843f-8793608124e1 May 30 00:07:15 localhost setroubleshoot[8535]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that dbus-broker should be allowed getopt access on the system_bus_socket unix_stream_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'dbus-broker' --raw | audit2allow -M my-dbusbroker#012# semodule -X 300 -i my-dbusbroker.pp#012 May 30 00:07:15 localhost setroubleshoot[8535]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l b8ec7109-2643-448e-843f-8793608124e1 May 30 00:07:15 localhost setroubleshoot[8535]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that dbus-broker should be allowed getopt access on the system_bus_socket unix_stream_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'dbus-broker' --raw | audit2allow -M my-dbusbroker#012# semodule -X 300 -i my-dbusbroker.pp#012 May 30 00:07:26 localhost setroubleshoot[8535]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l b8ec7109-2643-448e-843f-8793608124e1 May 30 00:07:26 localhost setroubleshoot[8535]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that dbus-broker should be allowed getopt access on the system_bus_socket unix_stream_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'dbus-broker' --raw | audit2allow -M my-dbusbroker#012# semodule -X 300 -i my-dbusbroker.pp#012 May 30 00:08:26 localhost setroubleshoot[9111]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l b8ec7109-2643-448e-843f-8793608124e1 May 30 00:08:26 localhost setroubleshoot[9111]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket.#012#012***** Plugin catchall (100. confidence) suggests **************************#012#012If you believe that dbus-broker should be allowed getopt access on the system_bus_socket unix_stream_socket by default.#012Then you should report this as a bug.#012You can generate a local policy module to allow this access.#012Do#012allow this access for now by executing:#012# ausearch -c 'dbus-broker' --raw | audit2allow -M my-dbusbroker#012# semodule -X 300 -i my-dbusbroker.pp#012 BTW, it works on kernel-5.12.7-300.fc34.x86_64
(In reply to Arun Babu Neelicattu from comment #7) > Similar issue. Using kernal and selinux packages from update-testing seems > to have helped. > > > sudo dnf upgrade --enablerepo=updates-testing kernel* selinux* > > The following packages are now installed and boot succeeds. > > > kernel-core-5.12.7-300.fc34.x86_64 > > kernel-modules-5.12.7-300.fc34.x86_64 > > kernel-modules-extra-5.12.7-300.fc34.x86_64 > > kernel-devel-5.12.7-300.fc34.x86_64 > > kernel-debug-devel-5.12.7-300.fc34.x86_64 > > selinux-policy-34.9-1.fc34.noarch > > selinux-policy-minimum-34.9-1.fc34.noarch > > selinux-policy-targeted-34.9-1.fc34.noarch I tried to install the packages you suggested, however the same behaviour applies (the boot process still fails after a long hang on "Switch root") - I tried again to boot the newer kernel 5.12.7 using the normal cmdline, and also by disabling SELinux; I observed a new error in addition to the first I described: mag 30 00:11:14 thinker dbus-broker-lau[1957]: Ready mag 30 00:11:25 thinker dbus-broker-launch[1957]: Activation request for 'org.freedesktop.ModemManager1' failed: The systemd unit 'dbus-org.freedesktop.ModemManager1.service' could not be found. ░░ Subject: Activation request failed due to missing unit ░░ Defined-By: dbus-broker ░░ Support: https://groups.google.com/forum/#!forum/bus1-devel ░░ ░░ systemd failed to activate the name org.freedesktop.ModemManager1 ░░ because the service dbus-org.freedesktop.ModemManager1.service could not be found. ░░ ░░ A possible reason for this is that dbus-org.freedesktop.ModemManager1.service is an ░░ alias to a disabled service. This is allowed by design, to give the ░░ administrator a way to disable name activation for a given service while ░░ still allowing it to be installed and potentially started in other ways. ░░ ░░ In order not to flood the logs, this message is only emitted once per name. mag 30 00:11:26 thinker dbus-broker[1995]: A security policy denied :1.41 to send method call /org/freedesktop/PackageKit:org.freedesktop.DBus.Properties.GetAll to :1.49. mag 30 00:11:26 thinker dbus-broker[1995]: A security policy denied :1.41 to send method call /org/freedesktop/PackageKit:org.freedesktop.DBus.Properties.GetAll to :1.49.
(In reply to Han Han from comment #8) > In terms of my machine, the it still hangs at "Switching Root" stage. > Version: kernel-5.12.7-300.fc34.x86_64 selinux-policy-34.9-1.fc34.noarch > If I set "enforcing=0" to the cmdline of kernel-5.12.7-300.fc34.x86_64. It > will work around this problem. I boted with enforcing=0 and this time I could capture some setroubleshoot outpou (I could not see any of it with SELinux enabled and Enforcing, or completely disabled); I am not an expert on this topic, but could this boil down to some exception in the policies? Here it is the complete list of setroubleshoot lines throughout the boot process: -- Journal begins at Wed 2021-05-26 10:40:46 CEST, ends at Sun 2021-05-30 00:30:54 CEST. -- mag 30 00:29:38 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:39 thinker setroubleshoot[2073]: SELinux is preventing systemd-machine from connectto access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l 1bf3efdd-c7d2-4113-a206-a586682> mag 30 00:29:40 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:40 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:40 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l 7c587b0e-05b2-413b-8d62-1f3bb27a8bc8 mag 30 00:29:40 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:40 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:41 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l 7c587b0e-05b2-413b-8d62-1f3bb27a8bc8 mag 30 00:29:44 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:44 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:45 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:29:45 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:45 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:46 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:29:46 thinker setroubleshoot[2073]: failed to retrieve rpm info for /dev/shm mag 30 00:29:46 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from write access on the directory /dev/shm. For complete SELinux messages run: sealert -l 613514d3-5a63-4fdd-9a59-c742719e229a mag 30 00:29:46 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from add_name access on the directory dbus-1. For complete SELinux messages run: sealert -l 9973e423-9aea-47ab-9ffe-a13098ade59f mag 30 00:29:46 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from create access on the directory dbus-1. For complete SELinux messages run: sealert -l 66b767b3-35dd-4c0a-ba2c-26f687182125 mag 30 00:29:46 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from read access on the directory services. For complete SELinux messages run: sealert -l c5e94c4d-41df-470c-b08f-b5d2c3abfd33 mag 30 00:29:46 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:46 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:47 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:29:47 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:29:47 thinker abrt-notification[2786]: [🡕] Process 2366 (gnome-shell) crashed in meta_wayland_compositor_setup() mag 30 00:29:49 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:49 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:49 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:49 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:49 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:29:50 thinker setroubleshoot[2073]: SELinux is preventing gdb from read access on the file index. For complete SELinux messages run: sealert -l 715b24f6-7be8-40da-b796-ed01003e8d95 mag 30 00:29:50 thinker setroubleshoot[2073]: SELinux is preventing gdb from open access on the file /var/lib/gdm/.cache/mesa_shader_cache/index. For complete SELinux messages run: sealert -l 689e04b1-baa3-4343-ba1b-f21dcaffbfe7 mag 30 00:29:50 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from read access on the directory services. For complete SELinux messages run: sealert -l c5e94c4d-41df-470c-b08f-b5d2c3abfd33 mag 30 00:29:50 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:50 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:50 thinker setroubleshoot[2073]: SELinux is preventing modprobe from integrity access on the lockdown labeled tlp_t. For complete SELinux messages run: sealert -l 02d2242c-6541-4c7c-b32e-405cb2794e84 mag 30 00:29:51 thinker setroubleshoot[2073]: SELinux is preventing tpacpi-bat from write access on the file call. For complete SELinux messages run: sealert -l 92ad8fa4-4a01-4c55-a8d2-a76a827a1341 mag 30 00:29:51 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from read access on the directory services. For complete SELinux messages run: sealert -l c5e94c4d-41df-470c-b08f-b5d2c3abfd33 mag 30 00:29:55 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from read access on the directory services. For complete SELinux messages run: sealert -l c5e94c4d-41df-470c-b08f-b5d2c3abfd33 mag 30 00:29:55 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:55 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:55 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from read access on the directory services. For complete SELinux messages run: sealert -l c5e94c4d-41df-470c-b08f-b5d2c3abfd33 mag 30 00:29:55 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:55 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:55 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l 7c587b0e-05b2-413b-8d62-1f3bb27a8bc8 mag 30 00:29:56 thinker setroubleshoot[2073]: SELinux is preventing dbus-daemon from read access on the directory services. For complete SELinux messages run: sealert -l c5e94c4d-41df-470c-b08f-b5d2c3abfd33 mag 30 00:29:56 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:29:56 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:29:56 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:30:03 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:30:03 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:30:11 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:30:14 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:30:14 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:30:17 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:30:18 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:30:18 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:30:20 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l 7c587b0e-05b2-413b-8d62-1f3bb27a8bc8 mag 30 00:30:21 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l aeee32b2-eedf-42ac-bdd3-a1077d0a6eb3 mag 30 00:30:21 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from ioctl access on the unix_stream_socket unix_stream_socket. For complete SELinux messages run: sealert -l 7c587b0e-05b2-413b-8d62-1f3bb27a8bc8 mag 30 00:30:22 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:30:22 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17> mag 30 00:30:43 thinker setroubleshoot[2073]: failed to retrieve rpm info for /run/dbus/system_bus_socket mag 30 00:30:44 thinker setroubleshoot[2073]: SELinux is preventing /usr/bin/dbus-broker from getopt access on the unix_stream_socket /run/dbus/system_bus_socket. For complete SELinux messages run: sealert -l af63f5ab-5695-4cf8-9af8-65f17>
I tried to add all the policies suggested by setroubleshoot, as shown in comment #10, however I still experience the gnome-shell crash I reported in comment #4 (I am still tinkering with the 5.12.7)
Created attachment 1788058 [details] sealert-9b523112-c65b-408d-af46-86acf2e0c718.txt Adding the sealert details to provide context on failing dbus socket access. This might be related. Seems there was an update from the updates repository that installed kernel-5.12.7-300.fc34.x86_64 again, which made the problem re-appear. :(
I tried to setup and run a Fedora 34 Workstation virtual machine, on the same machine I'm having issues to boot with a kernel newer than 5.11.20: The VM boots without issues, and also has none of the problems I got after upgrading to kernels 5.12.*; I updated the VM to the latest 5.12.8 kernel and it booted also without any SELinux issues, nor gnome-shell crashing on XWayland. I used KVM to create the VM, and I chose to run an EFI machine with secure boot enabled (like my laptop, which has those issues at boot). Still, I cannot correlate the "dbus-broker-launch[1314]: Non unix-domain-socket passed as listener" exception to my specific hardware configuration. Do you have any suggestion or ideas?
I have a similar boot problem, but: - I am running Fedora 33 - I have three copies of F33 installed, all X64_86 on an old whitebox AMD Dual Athlon, a Lenovo T440 (i5) and a Lenovo R61i (Core Duo). - All were updated (dnf update) to F33 5.11.21-200.fc33.x86_64 on May 28 between 15:00 and 18:00 - The AMD and T440 boot without issues, but the R61i will not boot from this version, but boots without any problems from 5.11.21-200.fc33.x86_64 - Symptoms for the R61i - it apparently boots OK and seems to have started all the expected background tasks including Fahclient, a protein folding application - Visually, it gets as far as putting the mouse pointer on the center of an otherwise featureless black screen, i.e. just before it shows the splash screen and login box. - it seems to all go wrong just on 6 minutes after boot started when it reports: May 27 20:12:46 cretin.gregorie.lan at-spi2-registryd[2387]: SpiRegistry daemon is running with well-known name - org.a11y.atspi.Registry May 27 20:15:22 cretin.gregorie.lan kernel: perf: interrupt took too long (6179 > 6167), lowering kernel.perf_event_max_sample_rate to 32000 May 27 20:16:58 cretin.gregorie.lan rsyslogd[614]: imjournal: 1964494 messages lost due to rate-limiting (20000 allowed within 600 seconds) May 27 20:17:05 cretin.gregorie.lan rsyslogd[614]: imjournal from <cretin:audit>: begin to drop messages due to rate-limiting May 27 20:17:22 cretin.gregorie.lan rsyslogd[614]: imjournal: journal files changed, reloading... [v8.2010.0 try https://www.rsyslog.com/e/0 ] May 27 20:20:13 cretin.gregorie.lan systemd[1]: Starting system activity accounting tool... - at about the same time as I hit 'power off' it reported May 27 20:30:13 cretin.gregorie.lan audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=sysstat> May 27 20:30:13 cretin.gregorie.lan rsyslogd[614]: imjournal: 57105 messages lost due to rate-limiting (20000 allowed within 600 seconds) May 27 20:36:58 cretin.gregorie.lan smartd[623]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 63 to 57 May 27 20:40:13 cretin.gregorie.lan systemd[1]: Starting system activity accounting tool... If you want anything else from this log, just ask...
Kernel version correction: Apologies for miscopied information in the previous post: the offending kernel is, of course, 5.12.6-200.fc33.x86_64 The AMD Dual Athlon whitebox and the Lenovo T440 are running successfully on it but the R61i will not boot using it All three systems were booting successfully on 5.11.21-200.fc33.x86_64 before 5.12.6-200 was installed The R61i is currently running successfully on 5.11.21-200.fc33.x86_64 after selecting it from the boot menu.
I have the same problem on my laptop after I upgraded to Fedora 34 few days ago. After that, I've encountered the following anomalies: * long delay on boot when starting initrd-switch-root.service ("Switch Root"); * multiple unsuccessful attempts to start dbus-broker.service with the following error message: "Non unix-domain-socket passed as listener"; * many other services fail to start as a result of dbus-broker.service faulure (like NetworkManager.service); * many missing directories that should have been created by systemd-tmpfiles-setup.service (for example, "/run/screen" is missing). So, I started debugging this problem. Here are important findings I've made. First, I started adding debug printing to dbus-broker-launch program to find out what is wrong with socket passed by systemd socket activation as file descriptor 3. And I found that although "/run/dbus/system_bus_socket" file exists and is indeed a socket, what is passed by systemd as descriptor 3 is actually "/dev/null". At least, it's a character device with major 1 and minor 3, exactly like "/dev/null". Also, I found that there was actually one successful dbus-broker launch during initrd stage, but this service got deactivated after "Switch Root" delay has ended, and multiple subsequent dbus-broker startup attempts were failing as a result of passing "/dev/null" instead of socket as I described. Eventually, dbus-broker starts successfully later, but many other services fail to start in the meantime. Second, I've confirmed that passing "enforcing=0" as kernel command line option at boot helped to work around dbus-broker startup problem, but did not fix delay at "Switch Root" and tmpfiles problem I've mention above. Third, downgrading to older kernel (like 5.11.12 as I did) fixes no problems. Fourth (and most important): however, downgrading dracut to 053-4.fc34 (and re-creating initrd after that) solved all these problems. Hence, the problem is not in kernel, not in dbus-broker, and not even in selinux-policy. The problem is in dracut, in the way how it generates initrd.
And here is a bug related to Dracut that seems to be related to this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1965859
One more related bug: https://bugzilla.redhat.com/show_bug.cgi?id=1965585
(In reply to Oleg Girko from comment #19) Hi, I'm happy to confirm that the procedure suggested by Oleg Girko has fixed the DBus Broker boot issue on the kernel 5.12.8. Here are the steps I performed to accomplish it: On boot, hold Shift to bring up the GRUB menu and select a kernel that you are still able to get a shell on; in my case, I could boot the 5.11.20 kernel, so I had access to the graphical shell, so the following commands are what I entered from a tty session of my logged user: sudo dnf install dracut-053-4.fc34 export LATEST_KERNEL="5.12.8-300.fc34.x86_64" sudo cp /boot/initramfs-${LATEST_KERNEL}.img /boot/initramfs-${LATEST_KERNEL}.bak.$(date +%m-%d-%H%M%S).img dracut -f /boot/initramfs-${LATEST_KERNEL}.img ${LATEST_KERNEL} Then, I rebooted, selected the 5.12.8 kernel, and it went straight to the Plymouth screen, without any errors. Thanks Oleg!
I'm still on Fedora 33 and have just run my usual weekly dnf update on all three systems (AMD Dual Athlon, Lenovo R61i, Lenovo T440). This installed kernel 5.12.8-200.fc33.x86_64 and all three are now booting correctly.
(In reply to Lorenzo Prosseda from comment #22) > (In reply to Oleg Girko from comment #19) > > Hi, I'm happy to confirm that the procedure suggested by Oleg Girko has > fixed the DBus Broker boot issue on the kernel 5.12.8. Here are the steps I > performed to accomplish it: > > On boot, hold Shift to bring up the GRUB menu and select a kernel that you > are still able to get a shell on; in my case, I could boot the 5.11.20 > kernel, so I had access to the graphical shell, so the following commands > are what I entered from a tty session of my logged user: > > sudo dnf install dracut-053-4.fc34 > > export LATEST_KERNEL="5.12.8-300.fc34.x86_64" > > sudo cp /boot/initramfs-${LATEST_KERNEL}.img > /boot/initramfs-${LATEST_KERNEL}.bak.$(date +%m-%d-%H%M%S).img > > dracut -f /boot/initramfs-${LATEST_KERNEL}.img ${LATEST_KERNEL} > > > Then, I rebooted, selected the 5.12.8 kernel, and it went straight to the > Plymouth screen, without any errors. > Thanks Oleg! Works for me on kernel-5.12.9-300.fc34.x86_64, too
I was bisecting commits in Dracut Git repo and found that the problem is caused by Bluetooth support. See https://github.com/dracutdevs/dracut/issues/1521#issuecomment-855318672 for the exact commit number.
And please note that Bluetooth in initrd is needed only to allow using Bluetooth keyboard early at boot time. It's not installed if you have no Bluetooth keyboards. You can remove all keyboards from your Bluetooth configuration and re-generate initrd as a workaround. See https://github.com/dracutdevs/dracut/issues/1521#issuecomment-855325340 for details.
Just a note to people following @Oleg / @Lorenza's advice above to force dracut to rebuild: make sure you take your LATEST_KERNEL variable from `uname -a` or similar. # uname -a (checkout output and modify next line as necessary) # export LATEST_KERNEL="5.12.8-300.fc34.x86_64" This will be needed if (like me) you initially did `dnf update --enablerepo=updates-testing` before finding your way here!
Can confirm, Oleg's workaround works for my case too. And I do have couple of bluetooth devices connecting at boot. In addition to Colin's comment, if you run updates, you might want to use "--exclude=dracut" to avoid the broken version being installed again and recreating the image.
*** Bug 1969237 has been marked as a duplicate of this bug. ***
*** Bug 1965859 has been marked as a duplicate of this bug. ***
*** Bug 1965585 has been marked as a duplicate of this bug. ***
Flagging for CommonBugs and nominating as a prioritized bug. This seems like a pretty bad problem.
ascheel confirmed he did have a bluetooth device configured as well, so it seems like everyone reporting this bug is hitting the bluetooth case, unless I missed anyone. So I think as a short-term mitigation I will do a build with the bluetooth support reverted. Once the bug is properly fixed we can put it back again.
FEDORA-2021-a3ab421a63 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a3ab421a63
I've edited the updates to include a dracut patched to never include the bluetooth module automatically (the 'check' section always returns 1 or 255, never 0). You can still explicitly include it via configuration, for testing purposes. This isn't a fix but a workaround until upstream can fix the issue properly. Please let me know if there are any issues with it. Thanks!
I also wanted to confirm that I was being hit by this bug and that I also had a bluetooth keyboard (and mouse) configured. I will test the new dracut update and report back (my workaround was either regenerating initramfs with an older version of dracut or excluding bluetooth from the dracut config as described by Oleg).
What the update should do is leave the module out even if you have a bluetooth input device configured, with no need for a config snippet. So please test without that config snippet in place to be sure the change works. Thanks!
I was also impacted by the dracut issue (I once upon a time paired a BT keyboard) and I can confirm that the 055-2 dracut update fixes this, thank you.
FEDORA-2021-a3ab421a63 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a3ab421a63` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-a3ab421a63 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Can confirm the following updates dracut to 055-2 fixing the issue for my case. > sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-a3ab421a63
*** Bug 1971078 has been marked as a duplicate of this bug. ***
In today's Prioritized Bugs meeting[1], we rejected this as a Prioritized Bug. The update FEDORA-2021-a3ab421a63 is a sufficient workaround until upstream can make a proper fix [1] https://meetbot.fedoraproject.org/fedora-meeting-1/2021-06-16/fedora_prioritized_bugs_and_issues.2021-06-16-15.01.log.html#l-62
The fix did not seem to resolve the issue here. Unchanged behavior. Has happened with all 5.12 kernels so far. Incidentally, if booting in single mode, then exiting, booting completes. However gdm crashes and dumps core, as shown above. systemd restarts and ends up working: un 20 10:22:49 localhost.localdomain systemd[3912]: Reached target Main User Target. Jun 20 10:22:49 localhost.localdomain systemd[3912]: Startup finished in 305ms. Jun 20 10:22:49 localhost.localdomain gdm-launch-environment][3886]: pam_unix(gdm-launch-environment:session): session opened for user gdm(uid=42) by (uid=0) Jun 20 10:22:49 localhost.localdomain audit[3886]: USER_START pid=3886 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask acct="gdm" exe="/usr/libexec/gdm-session-worker" hostname=l> Jun 20 10:22:49 localhost.localdomain systemd[3912]: Created slice User Core Session Slice. Jun 20 10:22:49 localhost.localdomain systemd[3912]: Starting D-Bus User Message Bus... Jun 20 10:22:49 localhost.localdomain dbus-broker-launch[3955]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +31: Eavesdropping is deprecated and ignored Jun 20 10:22:49 localhost.localdomain dbus-broker-launch[3955]: Policy to allow eavesdropping in /usr/share/dbus-1/session.conf +33: Eavesdropping is deprecated and ignored Jun 20 10:22:49 localhost.localdomain systemd[3912]: Started D-Bus User Message Bus. Jun 20 10:22:49 localhost.localdomain dbus-broker-lau[3955]: Ready Jun 20 10:22:49 localhost.localdomain gnome-session[3960]: gnome-session-binary[3960]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Jun 20 10:22:49 localhost.localdomain gnome-session-binary[3960]: WARNING: Failed to upload environment to systemd: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Jun 20 10:22:49 localhost.localdomain gnome-session[3960]: gnome-session-binary[3960]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Jun 20 10:22:49 localhost.localdomain gnome-session-binary[3960]: WARNING: Failed to reset failed state of units: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Jun 20 10:22:49 localhost.localdomain gnome-session[3960]: gnome-session-binary[3960]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Jun 20 10:22:49 localhost.localdomain gnome-session-binary[3960]: WARNING: Falling back to non-systemd startup procedure due to error: GDBus.Error:org.freedesktop.DBus.Error.NameHasNoOwner: Name "org.freedesktop.systemd1" does not exist Jun 20 10:22:49 localhost.localdomain kernel: bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this. Jun 20 10:22:49 localhost.localdomain audit[3712]: NETFILTER_CFG table=firewalld:1;?:0 family=1 entries=0 op=nft_register_table pid=3712 subj=system_u:system_r:firewalld_t:s0 comm="firewalld" Jun 20 10:22:49 localhost.localdomain audit[3712]: NETFILTER_CFG table=firewalld:2;?:0 family=2 entries=0 op=nft_register_table pid=3712 subj=system_u:system_r:firewalld_t:s0 comm="firewalld" Jun 20 10:22:49 localhost.localdomain audit[3712]: NETFILTER_CFG table=firewalld:3;?:0 family=10 entries=0 op=nft_register_table pid=3712 subj=system_u:system_r:firewalld_t:s0 comm="firewalld" Jun 20 10:22:49 localhost.localdomain audit[3712]: NETFILTER_CFG table=?:0;?:0 family=0 entries=2 op=nft_register_gen pid=3712 subj=system_u:system_r:firewalld_t:s0 comm="firewalld" Jun 20 10:22:49 localhost.localdomain audit[3712]: SYSCALL arch=c000003e syscall=46 success=yes exit=172 a0=7 a1=7ffdde8c4920 a2=0 a3=7ffdde8b37bc items=0 ppid=1 pid=3712 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="firewalld" exe="/usr/bin/python3.9" > Jun 20 10:22:49 localhost.localdomain audit: SOCKADDR saddr=100000000000000000000000 Jun 20 10:22:49 localhost.localdomain audit: PROCTITLE proctitle=2F7573722F62696E2F707974686F6E33002D73002F7573722F7362696E2F6669726577616C6C64002D2D6E6F666F726B002D2D6E6F706964 Jun 20 10:22:49 localhost.localdomain systemd-udevd[3650]: Using default interface naming scheme 'v247'. Jun 20 10:22:49 localhost.localdomain systemd-udevd[3650]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable. Jun 20 10:22:49 localhost.localdomain systemd[1]: Starting WPA supplicant... Jun 20 10:22:49 localhost.localdomain NetworkManager[3834]: <info> [1624206169.5321] modem-manager: ModemManager available Jun 20 10:22:49 localhost.localdomain gnome-session[3960]: _IceTransmkdir: ERROR: euid != 0,directory /tmp/.ICE-unix will not be created. But then, X-Wayland won't start: Jun 20 10:22:50 localhost.localdomain gnome-shell[3973]: Failed to start X Wayland: Directory "/tmp/.X11-unix" is not writable (As mentioned above.) Eventually it revets to X11 and booting completes. Another detail: following messages appear, which did not show wth 5.11 kernels. Jun 20 10:22:29 localhost.localdomain systemd-sysv-generator[3410]: SysV service '/etc/rc.d/init.d/livesys-late' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Jun 20 10:22:29 localhost.localdomain systemd-sysv-generator[3410]: SysV service '/etc/rc.d/init.d/livesys' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust.
Hi! Are you sure you're actually seeing the same problem? As the diagnosis seemed pretty clear and multiple other reporters confirmed it did fix the problem for them. Does your problem go away if you rebuild the initramfs with an older dracut?
Pretty sure it is the same. However now that I regenerated the initramfs it's indeed working... Sorry about the confusion. I should have thought about that. Incidentally I still get these selinux messages: Jun 20 16:05:57 localhost.localdomain setroubleshoot[1858]: SELinux is preventing gnome-shell from write access on the sock_file dbus-cMfyipnWXN. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that gnome-shell should be allowed write access on the dbus-cMfyipnWXN sock_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'gnome-shell' --raw | audit2allow -M my-gnomeshell # semodule -X 300 -i my-gnomeshell.pp
ah, okay. yes, you do have to regenerate the initramfs manually in this case, it doesn't happen automatically on package update (we don't do that just in case the build happens to make things *worse* - if we did that, when a bug happened, you wouldn't be able to boot an old kernel to get around it...) the selinux denial is https://bugzilla.redhat.com/show_bug.cgi?id=1941853 .
FEDORA-2021-a3ab421a63 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
I kinda missed the moment to put this in commonbugs, so dropping the tag. I don't think anyone would've been sitting around for the last three months waiting for me to write a commonbugs note, either they figured this out or switched to Mint by now. :D Can anyone check if this works now if you forcibly enable the bluetooth module? Johann said in the upstream issue that the underlying problem should be fixed in dbus-broker now, if so, we could revert the patch that disabled the bluetooth module.
I tried to check this post Fedora 35 upgrade. Unfortunately the problem persists. Here is what I did; 1. I applied the lines [1] to the relevant file. 2. Regenerated initramfs. The result was that the module was successfully loaded (bluetooth keyboard connected at the LUKS screen). However, the boot sequence got stuck and then shortly after failed with dbus-broker being unhappy. The failure was noticibly quicker than the last time around though. Should a new issue be raised here? Or are we waiting for a new dbus-broker/dracut release seeing as the upstream issue is still open? [1] https://github.com/dracutdevs/dracut/blob/15398458685d376fef56b1bf6fe09ae7c68324c1/modules.d/62bluetooth/module-setup.sh#L10-L15
Hmm, probably does need a new bug in that case. Johann said upstream he thought it should be fixed by a change in dbus-broker back in July, but if you still see the problem now, clearly that didn't fix it. Technically we could re-open this, but I think a new report would be clearer. Thanks!
After upgrading my workstation to rawhide for F37 dogfooding purposes it hang for 30 seconds at switching root and then anything depending on dbus would fail to start with permission errors. Booting the F36 kernel and then creating a: /etc/dracut.conf.d/nobluetooth.conf with: omit_dracutmodules+=" bluetooth " in there, followed by re-generating the initrd works around this. Once more people start testing F37 I expect more people to get bitten by this, so it would be good to fix this soon if possible. One interesting curiosity about the system I'm seeing this in is that the disk was moved from on older mainboard to my current mainboard and as such the Bluetooth HCI now has another MAC then before, so I have 2 MAC dirs under /var/lib/bluetooth/ and the dir which actually has a paired keyboard described in it is the dir with the MAC from my previous mainboard.
Let me re-apply the fix, thanks for testing!
https://src.fedoraproject.org/rpms/dracut/pull-request/24
(In reply to Hans de Goede from comment #52) > After upgrading my workstation to rawhide for F37 dogfooding purposes it > hang for 30 seconds at switching root and then anything depending on dbus > would fail to start with permission errors. One thing that I forgot to ask... do you have any logs? Because according to upstream this should be already solved and we're simply removing the functionality as a workaround (there will be no fix without those logs). https://github.com/dracutdevs/dracut/pull/1521
(In reply to Pavel Valena from comment #55) > One thing that I forgot to ask... do you have any logs? Because according to > upstream this should be already solved and we're simply removing the > functionality as a workaround (there will be no fix without those logs). > > https://github.com/dracutdevs/dracut/pull/1521 I would be happy to: a) Check this still reproduces with all the latest F37 packages b) Collect logs Can you let me know which logs you exactly want ? After a long timeout the rootfs does get mounted (but no gdm due to dbus errors). So I should be able to gather e.g. journalctl -b 0 from a text vc, or otherwise journalctl -b -1 after booting a non broken initd. Is that what you want, or should I maybe add some cmdline options to get some more verbose output ?
(In reply to Hans de Goede from comment #56) > (In reply to Pavel Valena from comment #55) > > One thing that I forgot to ask... do you have any logs? Because according to > > upstream this should be already solved and we're simply removing the > > functionality as a workaround (there will be no fix without those logs). > > > > https://github.com/dracutdevs/dracut/pull/1521 > > I would be happy to: > > a) Check this still reproduces with all the latest F37 packages > b) Collect logs > > Can you let me know which logs you exactly want ? > > After a long timeout the rootfs does get mounted (but no gdm due to dbus > errors). So I should be able to gather e.g. journalctl -b 0 from a text vc, > or otherwise journalctl -b -1 after booting a non broken initd. Is that > what you want, or should I maybe add some cmdline options to get some more > verbose output ? Hello Hans, ideal would be a log from the boot using `rd.debug` added on kernel cmdline (rdsosreport.txt, dmesg, or journalctl should probably give you very similar ones). Anything as long as the corresponding error is there (verbose is good). https://fedoraproject.org/wiki/How_to_debug_Dracut_problems Thanks!
FEDORA-2022-0fb75a6d1c has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-0fb75a6d1c
FEDORA-2022-0fb75a6d1c has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-0fb75a6d1c` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0fb75a6d1c See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-0fb75a6d1c has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
Related upstream PR https://github.com/dracutdevs/dracut/pull/2234
This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. 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 '37'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 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.
Current Rawhide is still carrying 1521-Never-enable-the-bluetooth-module-by-default.patch , so this isn't really resolved downstream. It does look like there's been some movement upstream, so it would be good if dracut devs can look if maybe we'd be able to drop the patch now.
I also hope that https://github.com/dracutdevs/dracut/commit/0ecb038832038523a27f989d0eb82b45fb67861c is a better alternative to the 1521-Never-enable-the-bluetooth-module-by-default.patch patch.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 40 development cycle. Changing version to 40.
The patch was dropped, closing as it was resolved by rebase with upstream fix proper. Please reopen if the issue persists. Both F40 and Rawhide should ok now.