Boot loading time is very high

Hey. I know many people asked this question but I couldn’t find any helpful thread to solve my problem. My loading time is very high. The systemd-analyze shows about 1 minute and 40 seconds.

Startup finished in 9.811s (firmware) + 6.627s (loader) + 1.836s (kernel) + 14.843s (initrd) + 1min 6.498s (userspace) = 1min 39.617s 

graphical.target reached after 1min 6.474s in userspace

I tried to see criticals and this happened:

The time when unit became active or started is printed after the>
The time the unit took to start is printed after the "+" charact>

graphical.target @1min 6.474s
└─multi-user.target @1min 6.473s
  └─crond.service @57.796s
    └─systemd-user-sessions.service @57.718s +26ms  [RED]
      └─remote-fs.target @57.715s
        └─remote-fs-pre.target @57.714s
          └─iscsi-shutdown.service @57.546s +352us  [RED]
            └─network.target @57.540s
              └─wpa_supplicant.service @1min 167ms +167ms  [RED]
                └─basic.target @37.020s
                  └─dbus-broker.service @36.317s +698ms  [RED]
                    └─dbus.socket @36.202s
                      └─sysinit.target @36.188s
                        └─systemd-update-utmp.service @36.131s +>  [RED]
                          └─auditd.service @35.383s +745ms  [RED]
                            └─systemd-tmpfiles-setup.service @34>  [RED]
                              └─import-state.service @16.239s +4>  [RED]
                                └─local-fs.target @16.234s
                                  └─home.mount @15.905s +328ms  [RED]
                                    └─systemd-fsck@dev-mapper-fe>  [RED]
                                      └─local-fs-pre.target @12.>
                                        └─lvm2-monitor.service @>  [RED]
                                          └─dm-event.socket @4.0>
                                            └─system.slice
                                              └─-.slice

I put a [RED] note after the ones that were colored red. I deleted all my snaps and snapd also to maybe reduce the boot time but it’s still very high.

The systemd-analyze blame shows this:

29.744s systemd-journal-flush.service                           >
19.353s firewalld.service                                       >
17.688s sssd.service                                            >
13.090s udisks2.service                                         >
11.492s dracut-initqueue.service                                >
10.368s abrtd.service                                           >
 9.909s ModemManager.service                                    >
 9.809s systemd-cryptsetup@luks\x2d7674d04e\x2dda04\x2d4ce5\x2da>
 9.373s smartd.service                                          >
 8.669s plymouth-quit-wait.service                              >
 8.284s gssproxy.service                                        >
 7.874s lvm2-monitor.service                                    >
 7.836s NetworkManager-wait-online.service                      >
 7.149s systemd-udev-settle.service                             >
 6.802s switcheroo-control.service                              >
 5.170s initrd-switch-root.service                              >
 2.201s systemd-fsck@dev-mapper-fedora_localhost\x2d\x2dlive\x2d>
 2.119s systemd-fsck@dev-disk-by\x2duuid-127f2e8c\x2d7f30\x2d4db>
 1.984s lightdm.service                                         >
 1.894s systemd-fsck@dev-disk-by\x2duuid-879A\x2dB586.service   >
 1.580s avahi-daemon.service                                    >
 1.443s systemd-udevd.service                                   >
 1.316s rsyslog.service                                         >
 1.148s systemd-tmpfiles-setup-dev.service                      >
  980ms cups.service                                            >
  963ms NetworkManager.service                                  >
  896ms dmraid-activation.service                               >
  880ms polkit.service                                          >
  837ms systemd-tmpfiles-setup.service                          >
  808ms systemd-logind.service                                  >
  793ms systemd-vconsole-setup.service                          >
  752ms upower.service                                          >
  745ms auditd.service                                          >
  698ms dbus-broker.service                                     >
  637ms lm_sensors.service                                      >
  536ms systemd-sysctl.service                                  >
  508ms systemd-tmpfiles-clean.service                          >
  499ms systemd-journald.service                                >
  472ms rtkit-daemon.service                                    >
  420ms systemd-udev-trigger.service                            >
  416ms import-state.service                                    >
  410ms bluetooth.service                                       >
  406ms dnf-makecache.service                                   >
  404ms systemd-fsck-root.service                               >
  397ms systemd-random-seed.service                             >
  348ms chronyd.service                                         >
  341ms accounts-daemon.service                                 >
  333ms plymouth-read-write.service                             >
  328ms home.mount                                              >
  313ms sssd-kcm.service                                        >
  300ms user@1000.service                                       >
  284ms plymouth-switch-root.service                            >
  268ms systemd-modules-load.service                            >
  268ms systemd-remount-fs.service                              >
  250ms boot-efi.mount                                          >
  236ms initrd-parse-etc.service                                >
  208ms colord.service                                          >
  192ms dracut-cmdline.service                                  >
  176ms dev-hugepages.mount                                     >
  176ms dev-mapper-fedora_localhost\x2d\x2dlive\x2dswap.swap    >
  175ms dev-mqueue.mount                                        >
  173ms sys-kernel-debug.mount                                  >
  173ms kmod-static-nodes.service                               >
  168ms dracut-shutdown.service                                 >
  168ms boot.mount                                              >
  167ms wpa_supplicant.service                                  >
  167ms nfs-convert.service                                     >
  165ms systemd-backlight@backlight:amdgpu_bl0.service          >
  102ms var-lib-nfs-rpc_pipefs.mount                            >
   63ms sysroot.mount                                           >
   56ms systemd-update-utmp.service                             >
   49ms rpc-statd-notify.service                                >
   44ms dracut-pre-pivot.service                                >
   39ms livesys.service                                         >
   32ms initrd-cleanup.service                                  >
   31ms dracut-pre-udev.service                                 >
   30ms systemd-rfkill.service                                  >
   29ms user-runtime-dir@1000.service                           >
   26ms systemd-user-sessions.service                           >
   15ms plymouth-start.service                                  >
   14ms systemd-update-utmp-runlevel.service                    >
   14ms initrd-udevadm-cleanup-db.service                       >
   13ms sys-fs-fuse-connections.mount                           >
   13ms livesys-late.service                                    >
    7ms tmp.mount                                               >
    2ms sys-kernel-config.mount                                 >
  352us iscsi-shutdown.service 

Is there any way to reduce boot time and have it in like 20 - 30 seconds? Or anything.

I also experience delay in boot on Fedora 32

Startup finished in 1min 54.340s (firmware) + 7.123s (loader) + 1.606s (kernel) + 4.249s (initrd) + 1min 24.315s (userspace) = 3min 31.634s graphical.target reached after 1min 24.298s in userspace

kernel: 5.6.0-300.fc32.x86_64

Unless you’re actually using a modem, you can get rid of ModemManager.service by stopping, disabling and masking it. That saves about 10 seconds. If you’re not actually using lvm, do the same for .vm2-monitor.service and save almost 8 seconds more. In general, when posting the results of this, you can trim off anything that takes less than one second as being too small to worry about.

   Also, if the machine is battery-backed: suspend is a nice thing.  My old HDD-rust resumes in second or two.  And all things’ state is saved (didn’t tested with games).

Well I have a problem with this too. When I close the lid or suspend, I can no longer use it. I should hold the power button till the system shuts off and then start it again.

1 Like

Also i have that issue. i have system on my SSD drive installed.

Blockquotesystemd-analyze
Startup finished in 3.258s (firmware) + 6.604s (loader) + 4.749s (kernel) + 9.733s (initrd) + 1min 17.247s (userspace) = 1min 41.594s
graphical.target reached after 1min 17.177s in userspace

systemd-analyze
Startup finished in 3.258s (firmware) + 6.604s (loader) + 4.749s (kernel) + 9.733s (initrd) + 1min 17.247s (userspace) = 1min 41.594s
graphical.target reached after 1min 17.177s in userspace
[Zarathustra@localhost ~]$ systemd-analyze blame
1min 4.228s systemd-udev-settle.service >
40.179s lvm2-monitor.service >
7.252s NetworkManager-wait-online.service >
6.059s upower.service >
5.948s dracut-initqueue.service >
4.674s systemd-rfkill.service >
3.038s systemd-logind.service >
2.245s systemd-homed.service >
2.018s initrd-switch-root.service >
1.782s firewalld.service >
1.432s systemd-backlight@backlight:radeon_bl0.service >
1.210s systemd-udevd.service >
1.092s udisks2.service >
1.031s systemd-userdbd.service

any suggestions please.

Looks like your disk has an issue, on my 5 years old laptop:

~> systemd-analyze blame
7.751s dnf-makecache.service
6.146s NetworkManager-wait-online.service
5.284s systemd-udev-settle.service
3.258s lvm2-monitor.service
3.247s plymouth-quit-wait.service
1.989s lvm2-pvscan@8:3.service
1.216s upower.service
927ms initrd-switch-root.service
894ms firewalld.service
663ms systemd-logind.service

any idea how to solve that issues?

My F32 boots in 6 min… i live with this issue since march (F32 Beta) and couldn’t find any solution. So, guess you need to write on bugzilla (there’s similar issue). Here’s the link - 1818429 – Fedora 32 Hangs at Boot on udev initialization

2 Likes

Look for this solution (there’s patch for systemd). It works for me and other users.
https://bugzilla.redhat.com/show_bug.cgi?id=1830896

1 Like

is solved that issues?

is that issue solve https://download.copr.fedorainfracloud.org/results/oleastre/systemd/fedora-32-x86_64/01380154-systemd/

Yes, this one solved.

I’ve just enabled this repo for systemd update (dnf copr enable oleastre/systemd) and updated systemd (sudo dnf update systemd*). Then just disabled the repo. Guess you can find this patch on systemd master and rebuild your systemd from sources. But with oleastre corp repo it’s easier and faster ^)

can you please guide me more easy how to do it?

i have not quite good experience on linux. i am new comer and do not want damege something.

or will that issues solved on any updates ?

Ok…
Open terminal app from application menu.
Then in terminal command line write next commands:

  1. sudo dnf corp enable oleastre/systemd (you’ll be asked to enter your password)
  2. sudo dnf update systemd* (you’ll be informed about updating some systemd packages, answer “y” and wait for successful update operation)
  3. sudo dnf corp disable oleastre/systemd

Then just reboot your system.

1 Like

Hello Folks.
i am interesting in Linux and some special cool Features. Can anyone explain me, what about these 3 commands in terminal.
are they to do, for having faster pc boot? or is that for having secure and more savety boot to system against default boot process?
i want to learn and think about - hhm. can i do that 3 commands or did i crash with that my system
:blush:

Generally speaking, anything that you run as your regular user (without sudo and not as root) is highly unlikely to break you system…

Those systemd-analyze commands can be executed safely.

Usually, it’s a good idea to read the documentation of a package or command before executing it…

Example: systemd-analyze(1) - Linux manual page

1 Like

Hi, if read the above posts, some users have experienced some very high boot time (like 6 minutes). These three commands enables a copr repository that contains some patches created to mitigates that problem.

  1. sudo dnf copr enable oleastre/systemd enable the repository
  2. sudo dnf update systemd* update the systemd packages (those are updated from the copr repositories that you have just enabled since they are newer)
  3. sudo dnf copr disable oleastre/systemd disables the repository, because this is a user repository.
    This is a temporary solution until the Fedora systemd manteiner updates the systemd packages.

[Edit]
WARNING: do this only if you have this bug, because it can break the system or introduce vulnerabilities.

This if the Copr FAQ if you want to know more about it.

2 Likes

Don’t simply install another systemd package until you have confirmed that you are hit by a bug and you are aware of the potential consequences. Run the systemd-analyze tool first and show the output…

This is a potential thread to security and stability! Only do so if you know what you are doing! @dawson just spent his first day with a GNU/Linux - so maybe take it easy…

3 Likes

@dawson obviously my post was meant to clarify what those command are, you don’t need to run those command if you haven’t this specific problem and you know what you are doing. So please take my words simply as an explanation.
As @florian said (now deleted) you can break the system if you replace system level packages.

Excuse me if i haven’t warned you in my previous post, my bad. Thank you @florian to point this out. :slight_smile:

1 Like