The only reason I deleted it is that your post may be an answer to the previous (and original) poster, and just not to @dawson. I didn’t want to create extra confusion here.
However, it needs to be pointed out that replacing systemd is not a small thing…
NB: I can undelete the comment…
Yes in fact you are right, I edited my original post to include the warning.
thanks nerds 
take it easy…
hi.
i ran systemctl analyze blame and thats output:
Blockquotesystemd-analyze blame
1min 15.615s systemd-udev-settle.service >
46.611s lvm2-monitor.service >
7.849s NetworkManager-wait-online.service >
6.702s upower.service >
6.048s systemd-rfkill.service >
6.038s dracut-initqueue.service >
4.559s systemd-logind.service >
3.286s systemd-machined.service >
2.710s systemd-homed.service >
2.148s initrd-switch-root.service >
1.948s firewalld.service >
1.682s systemd-backlight@backlight:radeon_bl0.service >
1.200s systemd-udevd.service >
1.108s udisks2.service >
1.054s sssd.service >
1.053s systemd-journald.service >
1.008s systemd-userdbd.service
p.s. someone advised me to disable that: systemctl disable systemd-udev-settle.service
will that bug solved from systemd maintener from update?
if yes i will wait to it.
I guess this issue should be fixed in one of the future systemd updates by Fedora maintainers, but how long will it take…
I couldn’t wait cuz 6 min boot was really annoying.
Can anyone link the correspondig bug report? -That should give us a good indication on the progress of a potential fix and new build of the package. Thx.
Well, the topic is loading is very slow.
But how much slow, and the cause seems different for many.
@eugine had 6 mins boot time… and the bug he points to, suggest a link between Asus NV series laptops.
@zarathustra19 seems the only one here, with a more than 1 min systemd-udev-settle.service and a long (46 secs) lvm2-monitor.service.
@rbirkner seems to have an abnormally fast system, we should ask him what version he use, and what kind of disk he use
@arh, the original poster, seems to have a very similar to mine Fedora 32, with similar times to mine… I suggest it is a “normal” situation… I was not following previous Fedora versions, so for me it looks normal.
I suggest it might be easier to follow if different topics are opened.
Ok, i can give some links, related to this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1830896
Hope it will help!
P.S. btw my laptop is Asus G46VW (2012 year) and the problem was with lvm2-monitor.service and systemd-udev-settle.service
I don’t think it can be different issues… the main bug can be the same for this 4 cases. Look at the opened systemd github issue i’ve linked above
I did not check much your links yet…
Still, the solution patch seems to cache values in efivars.c…
So it would suggest that it is linked to UEFI?
And I don’t boot with UEFI…
as I don’t have /sys/firmware/efi directory.
And like I said, my boot time is similar to original poster…
But maybe I did not understood the problem… maybe the boot time is not very different if you boot from UEFI or MBR… is it?
Ok… what about your hardware config? and “systemd-analyze blame” output?
And i have to agree that original post doesn’t seem to be the same as mine 
@arh just have to optimize his systemd services.
On my installed Fedora 32 XFCE, it take about 1 min 6 secs, I think.
Here, on the Fedora 32 Live image (Cinnamon), I booted in 21 secs.
[liveuser@localhost-live ~]$ systemd-analyze time
Startup finished in 4.848s (kernel) + 3.916s (initrd) + 12.336s (userspace) = 21.101s
graphical.target reached after 12.320s in userspace
[liveuser@localhost-live ~]$ systemd-analyze blame
2.966s initrd-switch-root.service
2.816s plymouth-quit-wait.service
2.564s firewalld.service
2.441s udisks2.service
2.316s livesys.service
[liveuser@localhost-live ~]$ rpm -qa | grep ^systemd-2
systemd-245.4-1.fc32.x86_64
Huh… should see systemd-analyze from installed F32, cuz different systemd services can be enabled that takes more time to start
On my installed Fedora 32 XFCE no-UEFI mode:
[paul@localhost ventoy-1.0.09]$ systemd-analyze
Startup finished in 1.136s (kernel) + 3.673s (initrd) + 48.846s (userspace) = 53.657s
graphical.target reached after 48.838s in userspace
[paul@localhost ventoy-1.0.09]$ systemd-analyze blame
17.745s firewalld.service >
16.028s ModemManager.service >
14.919s udisks2.service >
12.537s systemd-journal-flush.service >
11.439s upower.service >
11.082s avahi-daemon.service >
10.741s rtkit-daemon.service
I cannot start my installed in UEFI mode becaue it was installed in non-UEFI mode.
Ok… let’s talk about hdd speed (you have hdd right? not ssd? 5200rpm?)
is is a 7200 rpm hdd…
Ok I installed systemd from the proposed COPR and now:
[paul@localhost ~]$ systemd-analyze time
Startup finished in 1.177s (kernel) + 3.683s (initrd) + 46.953s (userspace) = 51.815s
graphical.target reached after 46.945s in userspace
[paul@localhost ~]$ systemd-analyze blame
17.296s firewalld.service >
15.776s udisks2.service >
14.520s ModemManager.service >
12.776s upower.service >
12.734s systemd-journal-flush.service >
11.067s sssd.service >
10.788s avahi-daemon.service
[paul@localhost ~]$ rpm -qa |grep ^systemd
systemd-container-245.4-1.1.fc32.x86_64
systemd-libs-245.4-1.1.fc32.x86_64
systemd-245.4-1.1.fc32.x86_64
systemd-rpm-macros-245.4-1.1.fc32.noarch
systemd-udev-245.4-1.1.fc32.x86_64
systemd-pam-245.4-1.1.fc32.x86_64
Ok, this systemd patch isn’t about your case, it’s more about efivarfs and device initialization. But it won’t make any problem for you.
I’ve tried to use fedora on different laptops and desktop, and the main problem was about hdd. And believe me 1min boot is normal in most cases. SSD is the cure if you don’t want to “cut” systemd services startup list (you should learn more about systemd).
but mine is SSD disk not HDD.
normaly SSD should be more fast/
if i disable systemctl disable systemd-udev-settle.service
will break system?