Ask Your Question
0

My fedora 20 taking long time to boot

asked 2014-04-22 22:54:53 -0500

SDas gravatar image

updated 2014-04-23 11:25:08 -0500

From last some days my fedora is taking too long time to boot why this happening? Is there any solution ? In Fedora can I perform disk de-fragment or system restore like operations. The result of systemd-analyze blame command -

     4.624s firewalld.service
      4.226s user@42.service
      3.700s plymouth-quit-wait.service
      3.276s rsyslog.service
      3.115s accounts-daemon.service
      2.843s lvm2-monitor.service
      2.807s bluetooth.service
      2.619s chronyd.service
      2.603s rtkit-daemon.service
      2.593s ModemManager.service
      2.585s systemd-logind.service
      2.460s avahi-daemon.service
      2.403s systemd-fsck@dev-disk-by\x2duuid-3b482cba\x2d0075\x2d44c1\x2d8a
      2.078s gdm.service
      1.504s proc-fs-nfsd.mount
      1.441s NetworkManager.service
      1.347s var-lib-nfs-rpc_pipefs.mount
      1.231s kmod-static-nodes.service
      1.220s plymouth-start.service
      1.188s nfs-lock.service
      1.152s systemd-fsck-root.service
      1.005s fedora-import-state.service
       997ms sys-kernel-debug.mount
       996ms dev-mqueue.mount
       995ms dev-hugepages.mount
       736ms colord.service
       699ms systemd-tmpfiles-setup-dev.service
       692ms tmp.mount
       665ms dev-disk-by\x2duuid-1bc0d1f7\x2d57f6\x2d492c\x2d8a8b\x2d756fcd7
       574ms fedora-readonly.service
       551ms boot.mount
       511ms sys-kernel-config.mount
       480ms systemd-sysctl.service
       475ms mcelog.service
       467ms systemd-udev-trigger.service
       465ms systemd-readahead-collect.service
       465ms systemd-readahead-collect.service
       453ms abrt-ccpp.service
       446ms systemd-readahead-replay.service
       405ms systemd-user-sessions.service
       388ms systemd-remount-fs.service
       309ms systemd-random-seed.service
       229ms polkit.service
       216ms systemd-tmpfiles-setup.service
       212ms systemd-udevd.service
       158ms user@1000.service
       155ms udisks2.service
       119ms auditd.service
       104ms plymouth-read-write.service
        77ms systemd-vconsole-setup.service
        58ms rpcbind.service
        56ms sshd.service
        43ms lvm2-lvmetad.service
        39ms systemd-journal-flush.service
        31ms upower.service
        19ms sys-fs-fuse-connections.mount
        17ms systemd-readahead-done.service
        15ms systemd-update-utmp-runlevel.service
         8ms systemd-update-utmp.service
edit retag flag offensive close merge delete

Comments

1

Please edit your question and add the results of systemd-analyze blame command in terminal.

NickTux gravatar imageNickTux ( 2014-04-23 00:45:37 -0500 )edit
1

And also the output of systemd-analyze critical-chain.

Ahmad Samir gravatar imageAhmad Samir ( 2014-04-23 01:00:27 -0500 )edit
1

And the total boot time is...?

skytux gravatar imageskytux ( 2014-04-23 14:30:35 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2014-04-23 13:50:06 -0500

NickTux gravatar image

If you didn't omitted anything on the results of systemd-analyze blame command, I cannot see anything extraordinary here about the boot time.

The only thing I can think is a bug that is still in action in Fedora 20 about the journal.log file. See the report (and the comments) here > https://bugzilla.redhat.com/show_bug.cgi?id=967521

The workaround, until this is fixed, is

sudo mv /var/log/journal /var/log/journal.old

reboot and see if any difference on boot time.

edit flag offensive delete link more

Comments

Nothing changed so much. So as your opinion with this I don't need to worry about!

SDas gravatar imageSDas ( 2014-04-26 12:16:11 -0500 )edit

Question Tools

1 follower

Stats

Asked: 2014-04-22 22:54:53 -0500

Seen: 2,647 times

Last updated: Apr 23 '14