Hide Forgot
Created attachment 1644447 [details] journalctl -b -o short-monotonic Description of problem: Boot process stops for 30 seconds with the message "A stop job is running for udev Kernel Device Manager" The exact symptoms described in https://github.com/systemd/systemd/issues/14128 are observed Version-Release number of selected component (if applicable): Fedora 31 running systemd-243.4-1.fc31 How reproducible: Always reproducible on every boot in my DELL latitude e6400 Steps to Reproduce: 1. Boot Fedora Actual results: 1. System takes more that 30 seconds to boot. 2. If "rhgb" is removed from GRUB's command line, the following systemd message appears for 30 seconds: "A stop job is running for udev Kernel Device Manager" Expected results: No extra delay should appear Additional info: My laptop dual boots Arch, running systemd-244-1, and it does have such delay In fact, an Arch user reported this bug upstream https://github.com/systemd/systemd/issues/14128 I've attached "boot.log" file which is the result of running "journalctl -b -o short-monotonic" Note the 30 second gap in: [ 2.923207] latitude-e6440 kernel: Finished initializing topology [ 3.371340] latitude-e6440 kernel: Console: switching to colour frame buffer device 240x67 [ 3.394986] latitude-e6440 kernel: i915 0000:00:02.0: fb0: i915drmfb frame buffer device [ 33.601134] latitude-e6440 systemd-udevd[339]: Giving up waiting for workers to finish. [ 33.602015] latitude-e6440 systemd-udevd[339]: Event loop failed: Connection timed out [ 33.604197] latitude-e6440 systemd[1]: systemd-udevd.service: Main process exited, code=exited, status=1/FAILURE [ 33.604767] latitude-e6440 systemd[1]: systemd-udevd.service: Failed with result 'exit-code'. [ 33.604873] latitude-e6440 systemd[1]: Stopped udev Kernel Device Manager. [ 33.605070] latitude-e6440 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-udevd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' [ 33.605232] latitude-e6440 systemd[1]: systemd-udevd.service: Consumed 1.757s CPU time. [ 33.605506] latitude-e6440 systemd[1]: systemd-udevd-control.socket: Succeeded.
My apologies, I meant Arch Linux, running systemd-244-1 does NOT have such delay.
I observe the same thing with my desktop PC. Using an Asus mother board with Xenon CPU and Nvidia GPU with Nvidia driver from rpmfusion. This only started recently. Earlier versions of F31 had no problems. I don't know if it is related, but the Plymouth boot screen stopped showing at the same time. Now I only get the black screen until SDDM starts.
systemd-243.5-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-29767c1981
FEDORA-2019-29767c1981 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-29767c1981
Updating to systemd-243.5-1 did not solve the issue for me.
*** Bug 1781329 has been marked as a duplicate of this bug. ***
systemd-243.5-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
Problems still persist.
Can somebody who is experiencing this attach an updated boot log (like in comment #0)?
Apologies for the noise. I noticed that the systemd in initramfs was still on the old version. I ran "sudo dracut -f" to rebuild initramfs, and now the problem is solved on boot for me (should a systemd update trigger an initramfs rebuild automatically?). Thanks for the fix.
Ha, I was suspecting that! > should a systemd update trigger an initramfs rebuild automatically? No. Systemd is only one of the things in the initramfs. In principle we could rebuild the initramfs every time a package that has files that end up in the initramfs gets updated, but that'd be very unwieldy, since rebuilding of the initramfs is slow, and we don't have a list of such packages. Also, people have more than one initramfs, and in principle we would have to rebuild all of them. Apart from being slow, rebuilding of the initramfs can easily go wrong... In the end, we currently only build the initramfs on kernel installation and never touch it afterwards.
Very much the same here: Simply updating the package did not solve the issue, but after rebuilding initramfs Thanks so much for the fix!