Fedora 32 very slow boot up/glitchy behavior

First of all it is unclear to me if this is really related to F32. I have rebooted before since installation and it was relatively quick. However all of a sudden, time from power on to main screen is something like 5 mins with some behavioral glitches. It takes quite a while to get to the login screen. Once there, the pointer will not move for at least a minute. Once it can move, I click my user name, and enter the password. It then hangs for another minute. It then kicks me back to user selection. I select the user again, type the password again, and wait again for another minute. It then finally gets me into the standard Gnome desktop. Sometimes I have to select user and enter password for a third time. This is also true of other DEs/WMs, not just Gnome. Once booted the performance is great! Systemd-analyze blame gives me the following output:

systemd-analyze blame
3min 48.919s lvm2-pvscan@8:7.service
2min 30.598s lvm2-monitor.service
58.988s plymouth-quit-wait.service
34.978s tlp.service
30.045s NetworkManager-wait-online.service
23.664s upower.service
11.828s systemd-fsck@dev-disk-by\x2duuid-9fc4d64f\x2d911b\x2d4b85\x2d9abf\x2de683fe2fae78.service
11.798s systemd-fsck@dev-disk-by\x2duuid-B4C4\x2d25D7.service
11.241s systemd-backlight@leds:asus::kbd_backlight.service
11.075s systemd-backlight@backlight:intel_backlight.service
9.864s user@1000.service
8.175s dnf-makecache.service
6.239s systemd-machined.service
6.173s systemd-homed.service
6.169s systemd-logind.service
6.130s systemd-update-utmp-runlevel.service
5.935s systemd-userdbd.service
5.539s systemd-tmpfiles-setup.service
5.517s systemd-update-utmp.service
5.515s systemd-user-sessions.service
5.321s user-runtime-dir@1000.service
4.719s initrd-switch-root.service
2.639s initrd-parse-etc.service
2.493s dracut-initqueue.service
2.442s systemd-fsck@dev-mapper-fedora_localhost\x2d\x2dlive\x2dhome.service
2.318s fwupd.service
1.528s systemd-journald.service
1.500s systemd-udev-trigger.service
927ms systemd-udevd.service
895ms firewalld.service
874ms dracut-cmdline.service
769ms systemd-tmpfiles-setup-dev.service
752ms systemd-sysctl.service
711ms systemd-random-seed.service
682ms systemd-repart.service
628ms systemd-vconsole-setup.service


LVM2 appears to be the culptrit, but google searching has provided no solutions to this. I do use LVM2 for my Fedora partition. There is another partition for a separate Linux installation. Fedora has been wonderful to use and again, this is only a problem on boot it seems. No other devices are plugged in during these reboots. Any help/direction you could give would be super appreciated.


same issue here… on my system main culprits are dracut-initqueue.service firewalld.service and NetworkManager-wait-online.service each taking above 20 seconds… Its total 2 mins in userspace. Its fedora specific problem other distros boot quickly on my hardware I dont know why fedora does not optimize this stuff.

1 Like

I had the same issue. The solution was found in installing upstream systemd.
I answered in another topic here - https://discussion.fedoraproject.org/t/boot-loading-time-is-very-high/75018

1 Like

slow boot based on lmv2-monitor.service doesn’t seem to be the same like yours with dracut-initqueue.service firewalld.service

Oh, cool! I have just solved the same issue on my machine, I have had it since upgrading from F31. So, I renamed these three rules files and it helped:

cd /usr/lib/udev/rules.d/
sudo mv 61-gdm.rules 61-gdm.rules.bkp
sudo mv 64-md-raid-assembly.rules 64-md-raid-assembly.rules.bkp
sudo mv 65-md-incremental.rules 65-md-incremental.rules.bkp
1 Like

I tried something like that before systemd patch installation… but it didn’t help. As i remember these manipulations with rules just reduced my F32 boot time for 2 minutes (from 6 to 4 minutes), but didn’t solve the mail problem. Systemd patch did.

Now i don’t have any problems about this theme.

As i can see on systemd github this patch will be delivered with systemd v246 - v246 Milestone · GitHub

1 Like

This is an old thread, sorry. Could you provide any source for this? This worked on a VM, but I’d like to know what I’m doing

I haven’t seen your post, sorry. Are you experiencing that problem? I thought it was solved already with a new version of systemd.

I just got the notification about your reply, this is a fast paced discussion. :smiley: No problem, thanks for replying anyway.

Yes, I had the problem and removing the udev rules you mentioned helped. There were also other issues that I had that should not have existed, like intel.fastboot kernel parameter that I heard should have been on by default, but not for me.

Unfortunately I did not have the time to participate in the F33 testing week, but if I can I will be trying 33 beta when it lands and trying to file bugs if I find them.