Bug 1830896
| Summary: | Very slow udev after upgrade to fedora 32 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | The Source <thesource> | ||||||||
| Component: | systemd | Assignee: | systemd-maint | ||||||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | urgent | Docs Contact: | |||||||||
| Priority: | unspecified | ||||||||||
| Version: | 32 | CC: | aivaraslaimikis, bugzilla.redhat, code, drewderivative, gmagic, hagtosmo, info, lnykryn, msekleta, osamarin68, pgnet.dev, ssahani, s, systemd-maint, turchi, udovdh, yuokada, zbyszek | ||||||||
| Target Milestone: | --- | ||||||||||
| Target Release: | --- | ||||||||||
| Hardware: | x86_64 | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | systemd-245.7-1.fc32 | Doc Type: | If docs needed, set a value | ||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2020-07-30 18:56:09 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
The Source
2020-05-04 09:03:49 UTC
I narrowed this problem down. It seems that when udev is executing IMPORT{cmdline} operation inside the rule, it takes long time. So removing some unneeded rules containing this operation greatly speeds up boot process. For my system I removed 61-gdm.rules, 64-md-raid-assembly, 65-md-incremental. The last two caused slowdown the most. I moved those 3 files to my home folder and remade the initrd using dracut. Now my system boost much faster.
I consider this a temporary workaround until IMPORT{cmdline} is fixed.
Please check this upstream discussion: https://github.com/systemd/systemd/issues/15739 It's likely that it is already fixed upstream. All these *.rules files are present in F31 as well. But udev works quickly in F31 Yes, a confirm than with all these systemd rules F31 boot was much quicker. Now i have the same problem... udev spends abot 4 minutes on lvm-monitor.service Created attachment 1687479 [details] Proposed upstream systemd patch to cache efi variables Applying upstream systemd patch on top of the fedora packages solves most of the issue for me. At least the system is more responsive; devices are detected as quick as it was in fedora 31. Not a I a slow HDD, so I don't know if this solves all speed issues. But at least it improves things. Upstream link: https://github.com/systemd/systemd/pull/15627 If it can be useful for anyone, I've rebuilt the systemd package with the included patch in a copr repository: https://copr.fedorainfracloud.org/coprs/oleastre/systemd/ Use it at your own risk. It works on my machine but that's the only guarantee I can give. (In reply to Olivier Samyn from comment #6) > If it can be useful for anyone, I've rebuilt the systemd package with the > included patch in a copr repository: > https://copr.fedorainfracloud.org/coprs/oleastre/systemd/ > Use it at your own risk. It works on my machine but that's the only > guarantee I can give. It helped me, thank you. (In reply to Olivier Samyn from comment #6) > If it can be useful for anyone, I've rebuilt the systemd package with the > included patch in a copr repository: > https://copr.fedorainfracloud.org/coprs/oleastre/systemd/ > Use it at your own risk. It works on my machine but that's the only > guarantee I can give. This systemd patch works for me. Thanx. The problem was with limits of efivarfs? It seems so, or maybe something to do with some hardware that is slow to answer I don't know. As the original poster, I also noticed the kernel worker efi_rts_wq at 100% CPU for a long time. Once that one was down to 0%, the system became usable. There are maybe other regressions regarding boot time, but at least the one related to devices enumeration and udev, seems to be solved with that patch. Created attachment 1687785 [details]
Patch for systemd-245.4 (fedora 32)
I can confirm that applying the patch to systemd-245.4-1 (present in Fedora32) resolves the problem of booting Fedora32
*** Bug 1833778 has been marked as a duplicate of this bug. *** With https://copr.fedorainfracloud.org/coprs/oleastre/systemd/ on my ASUS N56V no changes... Two questions to have a bit more context: - are you sure the systemd package has been updated ? or maybe you can try to re-package systemd with the proposed patch to see. - Can you give us a bit more info about your symptoms ? is your slowness coming from devices not accessible or something else ? The original reporter has a N56VB laptop and mine is a N56VZ (seems to be related to some bios versions), so it feel strange it does not change anything on yours. Sorry, my fault. The first time the upgrade of systemd failed partially (dnf was unable to update the i686 version). Now the patched version works well even for me. Thank you very much. There are some new commits upstream that claim to fix the issue (at least upstream issue is closed). I had the bad surprise today to get a systemd upgrade to version 245.6. That new version does not include the efivars cache patch, and of course it overrides my own compiled version. So, for the one relying on my copr, please wait before doing an update, I'll port the patch tomorrow. If there is a systemd package maintainer listening, would it be possible to add the proposed patch (efi variables caching) in the fedora package to at least avoid the impacted systems to be unresponsive for 10 minutes ? or to help me get it in the upstream systemd-stable branch ? I'm participating in the upstream issue to test some solutions while they are enhancing other related efi variables issues. But the proposed initial patch is already merged in systemd master, and it's required for impacted systems. Let's try to avoid another systemd update without this issue fixed. FEDORA-2020-2faf839786 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2faf839786 FEDORA-2020-2faf839786 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2faf839786` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2faf839786 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-2020-2faf839786 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report. *** Bug 1789906 has been marked as a duplicate of this bug. *** *** Bug 1818429 has been marked as a duplicate of this bug. *** We are running fedora 34 in the mean time... |