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 !
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)
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.
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.
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 !
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.
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.
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.
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.
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.
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 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
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.
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.