Boot is very slow in fedora32

My fedora32 takes about 1 minute 39 secs to bootup.
My system specs are : i3 6th gen, 4GB RAM, integrated graphics.
Is it normal for this system?? Coz i think it is slow

1 Like

Can you post the output of systemd-analyze blame so we can see what is slowing down your machine.

it should look like this:
~> systemd-analyze blame
6.171s NetworkManager-wait-online.service
…
when something is taking longer then getting online via WiFi there is an issue.

@kiko964 @rbirkner

29.791s firewalld.service >
27.755s upower.service >
29.791s firewalld.service >
27.755s upower.service >
26.575s sssd.service >
25.141s udisks2.service >
22.434s plymouth-quit-wait.service >
22.429s ModemManager.service >
19.163s unbound-anchor.service >
16.600s avahi-daemon.service >
16.594s bluetooth.service >
16.292s rtkit-daemon.service >
16.287s switcheroo-control.service >
16.284s systemd-homed.service >
16.282s systemd-machined.service >
16.268s abrtd.service >
16.063s systemd-journal-flush.service >
15.617s dbus-broker.service >
12.244s lvm2-monitor.service >
11.329s systemd-udev-settle.service >
7.931s initrd-switch-root.service >
6.803s NetworkManager-wait-online.service >
5.195s bolt.service >
4.823s dnf-makecache.service >
3.938s fwupd.service
4.823s dnf-makecache.service >
3.938s fwupd.service >
3.206s systemd-udevd.service >
2.756s libvirtd.service >
2.667s chronyd.service >
2.561s lm_sensors.service >
2.484s logrotate.service >
2.181s systemd-rfkill.service >
2.046s packagekit.service >
1.836s systemd-tmpfiles-setup-dev.service >
1.635s systemd-fsck@dev-disk-by\x2duuid-D679\x2d8769.service >
1.112s dracut-initqueue.service >
1.053s polkit.service >
1.015s dmraid-activation.service >
850ms systemd-random-seed.service >
791ms import-state.service >
753ms systemd-journald.service >
731ms systemd-sysctl.service >
723ms netcf-transaction.service >
707ms NetworkManager.service >
690ms systemd-tmpfiles-setup.service >
611ms systemd-logind.service >
502ms var-lib-nfs-rpc_pipefs.mount >
500ms systemd-userdbd.service >
491ms systemd-backlight@backlight:intel_backlight.service >
475ms boot-efi.mount >
427ms initrd-parse-etc.service >
398ms gdm.service >
387ms gssproxy.service >
383ms plymouth-switch-root.service >
359ms systemd-udev-trigger.service >
359ms plymouth-read-write.service >
353ms systemd-tmpfiles-clean.service >
351ms systemd-repart.service >
350ms nfs-convert.service >
333ms systemd-modules-load.service
256ms wpa_supplicant.service >
240ms dracut-shutdown.service >
232ms accounts-daemon.service >
227ms dev-disk-by\x2duuid-e0a46ed7\x2ddde5\x2d4948\x2db019\x2d0154c886d449.sw>
223ms systemd-fsck-root.service >
220ms geoclue.service >
218ms dev-hugepages.mount >
217ms dev-mqueue.mount >
216ms sys-kernel-debug.mount >
215ms user@1000.service >
214ms sys-kernel-tracing.mount >
214ms kmod-static-nodes.service >
208ms rpc-statd-notify.service >
198ms flatpak-system-helper.service >
170ms systemd-vconsole-setup.service >
157ms colord.service >
150ms systemd-remount-fs.service >
71ms dracut-pre-pivot.service >
70ms dracut-cmdline.service >
63ms livesys.service >
48ms initrd-cleanup.service >
48ms systemd-update-utmp.service
43ms dracut-pre-udev.service >
35ms systemd-user-sessions.service >
34ms tmp.mount >
34ms sysroot.mount >
26ms user-runtime-dir@1000.service >
19ms livesys-late.service >
16ms plymouth-start.service >
14ms initrd-udevadm-cleanup-db.service >
13ms systemd-update-utmp-runlevel.service >
5ms sys-fs-fuse-connections.mount >
4ms iscsi-shutdown.service >
3ms sys-kernel-config.mount

This is the output

Odd. The firewalld.service, and the upower.service are listed twice.

1 Like

@nrj The system takes 1 min and 39 secs to boot, nothing unusual if using a mechanical hard drive, my system takes 1 min 30 secs to boot.

Can you also post systemd-analyze time.

There are a number of recent threads on this issue. Have you looked at any of them, and if not, why not?

One thing I can tell you is that you can disable and mask ModemManager.service and recover over 22 seconds.

1 Like

@sideburns
as a noob I don’t know how to fix this

@kiko964
This time it took even more time to boot
Here is the output of systemd-analyze time

[nrj@localhost ~]$ systemd-analyze time
Startup finished in 4.227s (firmware) + 3.406s (loader) + 1.744s (kernel) + 6.102s (initrd) + 4min 57.004s (userspace) = 5min 12.486s
graphical.target reached after 2min 4.705s in userspace

@jochen is there a way to fix this??

@nrj Duplicates are the same starting service, i don’t think that the firewall service is starting twice with the exact same time.

To disable and mask the ModemManager.service type
systemctl stop ModemManager.service
systemctl disable ModemManager.service
systemctl mask ModemManager.service

@kiko964
I disabled and masked ModemManager.service
after this I booted the system again and typed systemd-analyze time
this was the output

Startup finished in 4.234s (firmware) + 3.169s (loader) + 1.709s (kernel) + 5.280s (initrd) + 1min 37.801s (userspace) = 1min 52.195s
graphical.target reached after 1min 37.780s in userspace

@nrj, don’t feel bad, everybody starts out as a beginner. Also, thee’s no one silver bullet to fix this. However, there have been a number of threads about this lately, with lots of ways of fixing this type of thing. Maybe, by reading through the threads and trying things that worked for others you can find the answer you need.

@sideburns
How can I be so stupid.
I read your previous suggestion to read other threads wrong.
My bad
I thought you were saying about faults shown in my output.
sorry.
I should search for similar threads now.

@sideburns
So I looked at few similar threads on this issue and found many different solutions.
There was a solution to replace systemd which i don’t think is safe for me to do.
There was also a solution to disable lvm2-monitor.service if I am not using lvm. But I dont know if I am using lvm or not so I searched a bit to how to find out this and got a solution to run < lvdisplay > on terminal to find out lvm availability which is not showing any output…?
So I looked at other threads and in one thread someone(I don’t remember the name sorry) asked to check the output of <journalctl --disk-usage>.
My output was :
Archived and active journals take up 592.1M in the file system.
which I think is causing systemd-journal-flush.service to take 27.180 seconds to complete.

There was one more thread to disable plymouth service which can reduce boot time by 50% but that was way more confusing…

Ok, here is a no-risk thing you can do:

journalctl --vacuum-time=15days

Or, however many days you wish to keep. That should clear out a lot of old journal logs and reduce your systemd-journal-flush.service time.

It will not cure everything, just that one aspect of your problems.

2 Likes

Vacuuming done, freed 3.5G of archived journals from /var/log/journal/d5cb82200d2348a584733b8c64c83a92.

This is awsome, thanks man! Why such house-keeping is not enabled by default?

1 Like

Finding the excess journals is exactly the type of thing we have to do, so Good Job! Now, about the lvm2 question, I get the same result as you do from lvdisplay, and I know that I’m not using lvm2, but let’s not take any chances. Please run df in a terminal and post the results, because that will tell me for sure if you’re using lvm2.

@sideburns

This is the output :

[nrj@localhost ~]$ df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1944292 0 1944292 0% /dev
tmpfs 1963612 61168 1902444 4% /dev/shm
tmpfs 1963612 1764 1961848 1% /run
/dev/sda3 409875992 16152636 372833040 5% /
tmpfs 1963612 120 1963492 1% /tmp
/dev/sda2 4186104 20820 4165284 1% /boot/efi
tmpfs 392720 140 392580 1% /run/user/1000
/dev/sda4 537070288 274731484 234987460 54% /run/media/nrj/Nrj

@blueshurricane4

I am confused. It didn’t clear anything. This is the output I got

[nrj@localhost ~]$ journalctl --vacuum-time=15days
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@0005a6062a340bcc-4d64ad57b57bd494.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@b3e087993e074b06a3cc629a4947df3e-0000000000000001-0005a601bbe1d2a9.journal: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/user-1000@0005a6062e2d8c9e-ca68426866255318.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@ed9a8d645a6741ebadd2783386f1b0a4-0000000000000001-0005a60628ba806c.journal: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/user-1000@89215328eaae40c88a5433a67a6e5937-0000000000000926-0005a6062e290d50.journal: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@0005a636b8ed3425-dc81648790a92271.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/user-1000@0005a636bd18680f-0da5b0451f09f190.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@0005a64b8e802107-ad60c11d61e65487.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/user-1000@0005a64b93a16bfc-8a31b2dfbc6ad927.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@0005a6ec1b1a345d-04560f36333b4495.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/user-1000@0005a6ec20dada5c-c5b35c34d98f479f.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/system@0005a77b1a17b4c5-0e07541ac12ed672.journal~: Permission denied
Failed to delete archived journal /var/log/journal/41403e33a01f47df84fdd965cca1305e/user-1000@0005a77b1ff11a07-3126313292cf3297.journal~: Permission denied
Vacuuming done, freed 0B of archived journals from /var/log/journal/41403e33a01f47df84fdd965cca1305e.
Vacuuming done, freed 0B of archived journals from /run/log/journal.

Am I supposed to run it with sudo??