Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1570793 - Slow boot time on Fedora 26 / 28 / 30
Summary: Slow boot time on Fedora 26 / 28 / 30
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: bootchart
Version: 30
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-04-23 12:18 UTC by yousifjkadom@yahoo.com
Modified: 2020-05-26 17:53 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-26 17:53:48 UTC
Type: Bug


Attachments (Terms of Use)

Description yousifjkadom@yahoo.com 2018-04-23 12:18:25 UTC
I was on Fedora 24 X64 bit Cinnamon edition. Boot time was reasonable. But when I upgraded from Fedora 24 to Fedora 26 by command line, I started to suffer from too long booting time. I posted about this in Fedora Forum but no one can help.

Before few days, I saw in Fedora forum other member suffer from same issue. Please look to this link:
https://forums.fedoraforum.org/showthread.php?317887-Fedora-27-booting-time

The thread talk about Fedora 27, but I have same problem: "Fedora really loading / starting each process twice"

Bellow the output of boot analysis of my system:

$ systemd-analyze blame
         17.611s firewalld.service
         17.397s fwupd.service
         17.384s systemd-journal-flush.service
         11.213s plymouth-quit-wait.service
         11.095s lvm2-monitor.service
         10.526s systemd-udev-settle.service
          9.623s NetworkManager-wait-online.service
          9.066s dev-mapper-fedora\x2droot.device
          7.613s udisks2.service
          7.608s accounts-daemon.service
          6.733s initrd-switch-root.service
          6.725s ModemManager.service
          5.429s lm_sensors.service
          4.744s rsyslog.service
          4.632s abrtd.service
          4.628s systemd-logind.service
          4.624s gssproxy.service
          4.621s livesys.service
          4.595s bluetooth.service
          4.474s avahi-daemon.service
          4.411s rtkit-daemon.service
          4.179s lvm2-pvscan@8:2.service
          3.937s lightdm.service
lines 1-23

-------------------

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 651ms
└─multi-user.target @1min 650ms
  └─crond.service @49.432s
    └─systemd-user-sessions.service @49.171s +177ms
      └─remote-fs.target @49.169s
        └─remote-fs-pre.target @49.168s
          └─iscsi-shutdown.service @49.167s
            └─network.target @49.102s
              └─wpa_supplicant.service @52.099s +443ms
                └─dbus.service @24.117s
                  └─basic.target @23.906s
                    └─sockets.target @23.906s
                      └─dbus.socket @23.906s
                        └─sysinit.target @23.863s
                          └─systemd-update-utmp.service @23.784s +77ms
                            └─auditd.service @22.900s +882ms
                              └─systemd-tmpfiles-setup.service @22.683s +201ms
                                └─systemd-journal-flush.service @5.297s +17.384s
                                  └─systemd-remount-fs.service @4.977s +317ms
                                    └─systemd-fsck-root.service @584542y 2w 2d 2
lines 1-23

-------------------

Please notice that I select "bootchart" as a component & I'm not sure is it what I should select or not. I do not know which component responsible for this. I select "bootchart" just to post this bug. Please correct it from your side.

Please your kind help !

Comment 1 yousifjkadom@yahoo.com 2018-04-23 12:21:02 UTC
My laptop details are: 

Lenovo ThinkPad e550 with Intel core i7 5500 CPU @ 2.40 GH X 2, RAM = 8 GB, HHD = 1 TB, Hybrid VGA (Intel Corporation HD Graphic 5500 + Radeon R7 M265 2GB)

Comment 2 Fedora End Of Life 2018-05-03 07:51:01 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 3 Fedora End Of Life 2018-05-29 11:19:51 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 4 yousifjkadom@yahoo.com 2018-06-05 11:06:18 UTC
Hi. I upgraded from Fedora 26 to Fedora 28 by DNF without any error message.

Issue IMPROVED but not fixed ! On Fedora 26 booting time was about 3 & 1/2 minutes ! Now, on Fedora 28 it is exactly = 2 & 1/2 minutes: less by about 1 minute ! 

But still long booting time !

These are the output on Fedora 28:

First:
$ systemd-analyze blame
   12min 10.550s dnf-makecache.service
         31.832s udisks2.service
         30.218s NetworkManager-wait-online.service
         23.559s firewalld.service
         22.087s plymouth-quit-wait.service
         20.812s systemd-journal-flush.service
         19.712s accounts-daemon.service
         11.448s lvm2-monitor.service
         10.535s NetworkManager.service
         10.359s ModemManager.service
          9.786s systemd-udev-settle.service
          9.246s polkit.service
          8.415s abrtd.service
          8.382s rtkit-daemon.service
          8.369s lm_sensors.service
          8.364s gssproxy.service
          8.194s cups.service
          8.151s avahi-daemon.service
          7.971s systemd-logind.service
          7.935s rsyslog.service
          7.933s unbound-anchor.service
          7.932s livesys-late.service
          7.258s initrd-switch-root.service
lines 1-23...skipping...
   12min 10.550s dnf-makecache.service
         31.832s udisks2.service
         30.218s NetworkManager-wait-online.service
         23.559s firewalld.service
         22.087s plymouth-quit-wait.service
         20.812s systemd-journal-flush.service
         19.712s accounts-daemon.service
         11.448s lvm2-monitor.service
         10.535s NetworkManager.service
         10.359s ModemManager.service
          9.786s systemd-udev-settle.service
          9.246s polkit.service
          8.415s abrtd.service
          8.382s rtkit-daemon.service
          8.369s lm_sensors.service
          8.364s gssproxy.service
          8.194s cups.service
          8.151s avahi-daemon.service
          7.971s systemd-logind.service
          7.935s rsyslog.service
          7.933s unbound-anchor.service
          7.932s livesys-late.service
          7.258s initrd-switch-root.service
          6.897s dev-mapper-fedora\x2droot.device
          5.312s bluetooth.service
          4.465s lightdm.service
          4.243s packagekit.service
          3.784s colord.service
          3.553s dracut-initqueue.service
          3.484s fwupd.service
          3.311s lvm2-pvscan@8:2.service
          2.271s systemd-udevd.service
          1.785s dmraid-activation.service
          1.303s fedora-readonly.service
          1.244s systemd-vconsole-setup.service
          1.182s systemd-tmpfiles-setup-dev.service

Second:
$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 24.982s
└─multi-user.target @1min 24.982s
  └─crond.service @1min 3.010s
    └─systemd-user-sessions.service @1min 2.720s +168ms
      └─remote-fs.target @1min 2.718s
        └─remote-fs-pre.target @1min 2.718s
          └─iscsi-shutdown.service @1min 2.621s
            └─network.target @1min 2.621s
              └─wpa_supplicant.service @1min 9.846s +796ms
                └─dbus.service @28.324s
                  └─basic.target @28.256s
                    └─dnf-makecache.timer @28.256s
                      └─sysinit.target @28.225s
                        └─systemd-update-utmp.service @28.051s +173ms
                          └─auditd.service @26.932s +1.115s
                            └─systemd-tmpfiles-setup.service @26.558s +358ms
                              └─systemd-journal-flush.service @5.744s +20.812s
                                └─systemd-journald.service @5.036s +704ms
                                  └─systemd-journald-audit.socket
                                    └─system.slice
lines 1-23/24 96%...skipping...
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 24.982s
└─multi-user.target @1min 24.982s
  └─crond.service @1min 3.010s
    └─systemd-user-sessions.service @1min 2.720s +168ms
      └─remote-fs.target @1min 2.718s
        └─remote-fs-pre.target @1min 2.718s
          └─iscsi-shutdown.service @1min 2.621s
            └─network.target @1min 2.621s
              └─wpa_supplicant.service @1min 9.846s +796ms
                └─dbus.service @28.324s
                  └─basic.target @28.256s
                    └─dnf-makecache.timer @28.256s
                      └─sysinit.target @28.225s
                        └─systemd-update-utmp.service @28.051s +173ms
                          └─auditd.service @26.932s +1.115s
                            └─systemd-tmpfiles-setup.service @26.558s +358ms
                              └─systemd-journal-flush.service @5.744s +20.812s
                                └─systemd-journald.service @5.036s +704ms
                                  └─systemd-journald-audit.socket
                                    └─system.slice
                                      └─-.slice
~
~
~
~
~
~
~
~
~
~
~
~

By the way, there is a discussion about similar issue in Fedora community forum at this link:

https://forums.fedoraforum.org/showthread.php?318121-Fedora-28-slow-boot-time

Please notice that my user name in Fedora community forum is "User808". 

Please look for my comment #4 & replay on it in comment #5 in the Fedora thread.

So, please what your opinion about the use of the following 2 commands:

sudo dracut -fv

then:

sudo touch /. autorelable

My SELinux state is "enforcing".

And I asking you here: does these 2 commands carry risk to damage my system ? In the forum "MarcvdM" said "probably yes" !

Please your kind help !

Comment 5 yousifjkadom@yahoo.com 2018-08-13 06:15:39 UTC
Hi. After months from using Fedora 28, I re-open this bug again because the following:

1st of all there is REAL improvement with Fedora 28 in comparison with 26. 

But I compare my Linux laptop with 2nd laptop using same USB, To copy/past SAME items from both laptops (each at separate occasion) to this USB.

Data of my Linux system:
Fedora 28 X64 bit Cinnamon edition on Lenovo ThinkPad e550 with Intel core i7 5500 CPU @ 2.40 GH X 2, RAM = 8 GB, HHD = 1 TB, Hybrid VGA (Intel Corporation HD Graphic 5500 + Radeon R7 M265 2GB

Data of 2nd laptop:
Windows 7 Ultimate SP1 X32 bit on HP pavilion g6 (Hewlett-Packard) with intel(R) Core(TM) i3-2310M CPU @ 2.10 GHz 2.10 GHz, RAM 4 GB (2.45 GB usable)

Data about items copied/pasted:
2 folders, 1st of 237 MB & 2nd of 44.4 MB.

The time periods for each:
1) on my Linux system, it took 42 seconds; while

2) on Windows system it took 61 seconds.

So, is this O.K ?! Only 19 seconds faster on Linux, 64 bit Cinnamon with core i7 (while only i3 for windows) with 8 GB RAM (while only 2.45 GB on Windows)

Please evaluate these data & if not a bug, kindly, close it.

Best.

Comment 6 yousifjkadom@yahoo.com 2018-08-13 13:34:11 UTC
Hi. 

I did a mistake by post "comment 5" here! It is not related to this bug! I post here wrongly! 

It is related to this bug that I re-opened it just few minutes when I recognized my mistake! I copy "comment 5" that I post it wrongly here, to the bellow correct bug site:
https://bugzilla.redhat.com/show_bug.cgi?id=1551193

I'm sorry for that. I can not delete it, so please either delete or at lest hide it (if you can not delete it) so as not to confusing peoples.

Comment 7 Ben Cotton 2019-05-02 21:09:46 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 Ben Cotton 2019-05-28 22:07:19 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 9 yousifjkadom@yahoo.com 2019-06-01 20:08:56 UTC
Hi. I upgraded from Fedora 28 to 30 using CLI via tty terminal, but this issue is still existing ! My booting time is 2 minutes & 11 seconds.

Comment 10 flaviusglamfenix 2019-11-20 20:36:15 UTC
I also have the same problem with long boot because of lvm2-monitor.service.
Fedora 30 x64_86
/boot is a standard partition.
/ and /home is part of LVM group.

Here are my results:
systemd-analyze 
Startup finished in 2.603s (kernel) + 7.693s (initrd) + 45.490s (userspace) = 55.787s 

systemd-analyze blame
         27.123s dkms.service
         17.521s firewalld.service
         14.168s udisks2.service
         10.712s sssd.service
          8.674s lvm2-monitor.service
          8.322s initrd-switch-root.service
          7.323s systemd-udev-settle.service
          7.279s vboxdrv.service
          7.202s avahi-daemon.service
          6.813s rtkit-daemon.service
          6.412s user@1002.service
          5.695s dbus-broker.service
          5.393s bluetooth.service
          4.771s smartd.service
          4.221s vpnagentd.service
          4.041s gssproxy.service
          3.877s dnf-makecache.service
          3.725s polkit.service
          3.020s dracut-initqueue.service
          2.279s chronyd.service

Both dkms and firewalld have a hang waiting for lvm2-monitor to start up.

systemd-analyze critical-chain dkms.service
The time when unit became active or started is printed after the "@" characte>
The time the unit took to start is printed after the "+" character.

dkms.service +27.123s
└─basic.target @18.224s
  └─dbus-broker.service @19.563s +5.695s
    └─dbus.socket @18.224s
      └─sysinit.target @18.177s
        └─systemd-update-utmp.service @18.123s +53ms
          └─auditd.service @17.156s +963ms
            └─systemd-tmpfiles-setup.service @16.446s +674ms
              └─local-fs.target @16.443s
                └─run-user-1002.mount @38.070s
                  └─local-fs-pre.target @15.003s
                    └─lvm2-monitor.service @6.328s +8.674s
                      └─lvm2-lvmetad.service @7.630s
                        └─lvm2-lvmetad.socket @6.074s
                          └─system.slice
                            └─-.slice

systemd-analyze critical-chain firewalld.service
The time when unit became active or started is printed after the "@" characte>
The time the unit took to start is printed after the "+" character.

firewalld.service +17.521s
└─polkit.service @27.613s +3.725s
  └─basic.target @18.224s
    └─dbus-broker.service @19.563s +5.695s
      └─dbus.socket @18.224s
        └─sysinit.target @18.177s
          └─systemd-update-utmp.service @18.123s +53ms
            └─auditd.service @17.156s +963ms
              └─systemd-tmpfiles-setup.service @16.446s +674ms
                └─local-fs.target @16.443s
                  └─run-user-1002.mount @38.070s
                    └─local-fs-pre.target @15.003s
                      └─lvm2-monitor.service @6.328s +8.674s
                        └─lvm2-lvmetad.service @7.630s
                          └─lvm2-lvmetad.socket @6.074s
                            └─system.slice
                              └─-.slice


systemd-analyze critical-chain lvm2-monitor.service
The time when unit became active or started is printed after the "@" characte>
The time the unit took to start is printed after the "+" character.

lvm2-monitor.service +8.674s
└─lvm2-lvmetad.service @7.630s
  └─lvm2-lvmetad.socket @6.074s
    └─system.slice
      └─-.slice

Comment 11 Ben Cotton 2020-04-30 20:42:14 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Ben Cotton 2020-05-26 17:53:48 UTC
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.