Fedora 22 slow boot (maybe it's a problem with /)

Hello everyone!

My GNU/Linux distribution is Fedora 22 Workstation and current kernel is 4.0.6-300. I have a trouble with Fedora's very slow boot -- it takes about 2m 50s from press power on to final desktop. Recently I have installed Slackware 14.1 to my computer and it was necessary to do a repartition on a hard disk. For this I used GParted and did a swapoff for Fedora's swap-section because without it I couldn't have an access to extended-section on a hard disk where I wanted to install Slackware. After Slackware's successfully installation I had mounted /swap and changed it's UUID in /etc/fstab. I really didn't done anything with Fedora's / and /home and just unmount and then mount /swap! I think that installation of a new distribution couldn't do anything with existing system but right after it I achieved my trouble so I retell it. Before this boot took just about 40-50 seconds but now it about 3 minutes.

The output of systemd-analyze time is:

Startup finished in 1.473s (kernel) + 1min 32.176s (initrd) + 59.913s (userspace) = 2min 33.563s

... systemd-analyze critical-chain:

graphical.target @59.906s
└─multi-user.target @59.906s
  └─crond.service @33.815s
    └─systemd-user-sessions.service @33.303s +316ms
      └─remote-fs.target @33.303s
        └─remote-fs-pre.target @33.303s
          └─iscsi-shutdown.service @33.302s
            └─network.target @33.211s
              └─wpa_supplicant.service @35.864s +851ms
                └─basic.target @19.405s
                  └─sockets.target @19.405s
                    └─cups.socket @19.405s
                      └─sysinit.target @19.386s
                        └─systemd-update-utmp.service @19.254s +130ms
                          └─auditd.service @19.122s +129ms
                            └─systemd-tmpfiles-setup.service @18.825s +294ms
                              └─systemd-journal-flush.service @4.169s +14.645s
                                └─systemd-remount-fs.service @4.133s +25ms
                                  └─systemd-fsck-root.service @3.278s +854ms
                                    └─systemd-journald.socket
                                      └─-.slice

... systemd-analyze blame:

1min 40.692s dev-sda7.device
         26.087s plymouth-quit-wait.service
         14.645s systemd-journal-flush.service
         10.436s firewalld.service
          9.616s systemd-udev-settle.service
          7.538s accounts-daemon.service
          5.270s cups.service
          2.970s lvm2-monitor.service
          2.600s polkit.service
          2.545s chronyd.service
          2.528s abrtd.service
          2.371s systemd-udevd.service
          2.077s packagekit.service
          2.075s systemd-logind.service
          2.040s mcelog.service
          1.877s systemd-fsck@dev-disk-by\x2duuid-b654c06b\x2d02c9\x2d4612\x2dacca\x2d3a59b177e899.service
          1.834s ModemManager.service
          1.831s gdm.service
          1.814s bluetooth.service
          1.810s avahi-daemon.service
          1.746s rtkit-daemon.service
          1.581s systemd-rfkill@rfkill0.service
          1.503s abrt-ccpp.service
          1.502s plymouth-start.service
          1.388s systemd-tmpfiles-setup-dev.service
          1.327s NetworkManager.service
           972ms dev-disk-by\x2duuid-416979d0\x2db3dc\x2d4831\x2da5e9\x2d31d3ef5b7a08.swap
           854ms systemd-fsck-root.service
           851ms wpa_supplicant.service
           828ms fedora-readonly.service
           741ms systemd-tmpfiles-clean.service
           564ms sys-kernel-debug.mount
           496ms tmp.mount
           494ms systemd-journald.service
           461ms systemd-random-seed.service
           439ms dev-mqueue.mount
           429ms fedora-import-state.service
           417ms dmraid-activation.service
           415ms systemd-backlight@backlight:intel_backlight.service
           392ms dnf-makecache.service
           377ms systemd-udev-trigger.service
           374ms systemd-sysctl.service
           366ms dev-hugepages.mount
           358ms dracut-shutdown.service
           316ms systemd-user-sessions.service
           294ms systemd-tmpfiles-setup.service
           281ms plymouth-read-write.service
           267ms colord.service
           233ms user@42.service
           229ms home.mount
           162ms kmod-static-nodes.service
           130ms systemd-update-utmp.service
           129ms auditd.service
            93ms user@1000.service
            86ms udisks2.service
            77ms upower.service
            65ms systemd-vconsole-setup.service
            40ms livesys.service
            25ms systemd-remount-fs.service
            25ms livesys-late.service
            22ms systemd-rfkill@rfkill1.service
             9ms sys-fs-fuse-connections.mount
             6ms systemd-update-utmp-runlevel.service
             2ms sys-kernel-config.mount

So you can see that it takes 1min 40s to boot /dev/sda7 which is / section for Fedora. I think it may be the critical thing that takes so much time.

What can it be and how can I solve it? Please, help, I really have no ideas.

P.S. Sorry for my English if there are any mistakes.

That initrd time is the problem - mine is 3.319s.
You could analyse it, but why not just rebuild it with dracut (after you do the swapon) - it's probably trying to sort out resume on a UUID that no longer exists.

Originally Posted by syg00 That initrd time is the problem - mine is 3.319s. You could analyse it, but why not just rebuild it with dracut (after you do the swapon) - it's probably trying to sort out resume on a UUID that no longer exists.

How can I rebuild it with dracut?
Should I do

dracut -f -v

to update initramfs or something else?

I have done dracut -f -v but boot time hadn't reduced at all. Today I also updated to kernel version 4.1.2-200.

Is there something in fstab that shouldn't be there?
In the past, I had an old swap UUID that was added, which resulted in long boot time.

Originally Posted by verndog Is there something in fstab that shouldn't be there? In the past, I had an old swap UUID that was added, which resulted in long boot time.

I checked it and there wasn't anything incorrect in it.

Now I have already switched to Slackware and don't use Fedora anymore.

i find that looking at a SVG output as a image is the MOST helpful for very fast seeing just what is holding things up

su -
systemd-analyze plot >/BootTime.svg

the red bars will tell you very fast what is holding things up

Hey Folks,

I did a bit of an experiment relative to firewalld slow to load rules into iptables. I was shocked at the results!!!

Experiment:
1) Create rules in firewalld via firewall-config
2) iptables-save > /etc/sysconfig/iptables (save the rules created by #1)
3) systemctl stop firewalld
4) manually reload the rules via cat /etc/sysconfig | iptables-restore
--- time to reload the rules (all 11,000 of them) 0.1 seconds
5) systemctl stop iptables (flush all the rules)
6) systemctl start firewalld ( have firewalld reload all the rules)
--- time to reload the rules (same 11,000 of them) .... 30 MINUTES!!!

So ....

1) Why is firewalld so slow to reload rules that can be loaded with iptables in less than 1 second?
2) How can I possibly justify using firewalld in any environment with performance as it stands today?
--- while firewalld is reloading the rules, my system is inaccessible until firewalld finally gets done loading the rules

Possible suggestion:
1) When rules are created with firewalld/firewall-config, why not just create a file in the same format as iptables-save and have iptables-restore load them into iptables? (0.1 seconds vs 30 minutes to load)
2) At system boot/start just let iptables reload the firewall rules via iptables

Why I am pursuing this:
1) I have longed for a tool like firewall-config for as long as ipchians-config gui tool was obsoleted
2) it makes it easier for me to train less experienced admins to use/configure iptables

ALSO:
Equipment I have run this experiment on:
1) Dell Optiplex 960 with 2x3GHz CPU and 8GB memory
2) HP EliteBook 8570 with 8x3.6GHz CPU and 32GB memory@1600MHz

It still took about 30 minutes to load the rules via firewalld on both....