Bug 1818429
Summary: | Fedora 32 Hangs at Boot on udev initialization | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Joshua <hagtosmo> | ||||||||
Component: | systemd | Assignee: | Orphan Owner <extras-orphan> | ||||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 32 | CC: | aivaras.laimikis, code, extras-orphan, fedoraproject, filbranden, flepied, gmagic, info, jonathan, lnykryn, m.koshelev, msekleta, ssahani, s, systemd-maint, thuryn1, yuwatana, zbyszek, z | ||||||||
Target Milestone: | --- | Keywords: | Bugfix | ||||||||
Target Release: | --- | ||||||||||
Hardware: | x86_64 | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2021-05-18 18:10:06 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: | |||||||||||
Attachments: |
|
Description
Joshua
2020-03-28 02:30:13 UTC
Created attachment 1674218 [details]
Picture of issue
I am still having this issue and now its worse because after installing nvidia drivers my screen shuts off after booting. After the display gets initialized during boot the monitor says no input detected and goes into power saving mode. Can confirm this. After system upgrade to Fedora 32 caught the same problem - long-long-long boot. Boot process hangs on udev Device Initialization. This process seems to last 3 minutes and more (Asus ROG G46VW). Same issue on the fresh updated F32 release + updates from testing repository. There was no such issue on Fedora 31. There 3 processes that fail cause of long device initialization: - Failed to start udev Wait for Complete Device Initialization (systemd-udev-settle.service failed which seems to be deprecated) - long lvm2 monitor (by the way i don't use lvm) - Failed to start Network Manager Wait Online Same issue with F32 live-usb. Even if i mask or disable lvm2-monitor.service or/and systemd-udev-settle.service (this one is called by lvm2-monitor.service), system boots in GDM in 30-50 secs, but with no wi-fi, mouse and keyboard initialized. In 3+ minutes after GDM boot all these devices is initialized. By the way lvm2-monitor seems to be "Done" but with warnings (WARNING: Device /dev/sdb6 not initialized in udev database even after waiting 10000000 microseconds.) So none of my sdaX or sdbX was initialized in udev database. I confirm the problem, I have 2 laptops, I updated from fedora 31 to 32. On the old one, with an Ivy Bridge processor, it takes more than 5 minutes to initialize any device and load the associated kernel modules. I tried various settings changes in the bios, or disabling some services, but nothing seems to solve that issue. If I wait long enough for all the devices to come up, the system is perfectly usable. I also tried a live image, and get the same problem. I'll try to get some kernel logs and attach here to show the problem. Created attachment 1684997 [details]
Kernel logs
As you can see from the attached kernel logs, the system takes almost 10 minutes to load the network and wifi devices.
And my attached USB mouse although early detected, becomes usable after 15 minutes (while the touchpad is available earlier, around the same time as the keyboard)
While trying to debug the issue, I noticed in top, a kernel "kworker:efi_rts_wq" thread running at 100% CPU. And that one disappear after a while (when system is usable, I don't see it any more in ps); don't know if it's related.
I can provide journalctl logs if needed.
Created attachment 1685558 [details]
Boot log with udev log set to debug
I did some further testing trying to find a problematic kernel module or something relevant.
Tried with selinux in permissive mode, not better.
So, here is a boot log with systemd-udevd booted with log_priority=debug.
There are some gaps in device detection, and I have the impression that some devices are detected multiple times.
If someone has tips what to search for, I would be happy to try stuff.
This is probably related to: https://bugzilla.redhat.com/show_bug.cgi?id=1830896 I'll make further testing today to verify if the proposed systemd patch works. (In reply to Olivier Samyn from comment #7) > This is probably related to: > https://bugzilla.redhat.com/show_bug.cgi?id=1830896 > I'll make further testing today to verify if the proposed systemd patch > works. will wait for your feedback (my alternative OS Clear Linux with fresh systemd seems to boot normal) This bug was filed against udev package, but that page is logn gone (and nobody looks at the bugs here). Reassigning to systemd. This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. 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 Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 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, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. *** This bug has been marked as a duplicate of bug 1830896 *** |