Description of problem: After upgrade from FC19 to FC20 with fedup boot is ridiculously slow. I see this problem on X220 laptop & i7 desktop. Both these machines are 64 bit and used to boot in seconds with FC19. Now the boot takes many minutes. I don't know for sure as have to leave it and come back later! Currently the laptop is booting and still showing Systemd messages 1600 seconds (almost half an hour) in! Systemd prints out many messages, at around 60 second intervals such as: Found dependency on sys initial.target/start Found dependency on local-fs.target/start Breaking ordering cycle by deleting job sockets.target/start Breaking ordering cycle by deleting job firewalld.service/stop Although the targets mentioned in both types of messages vary they do seem to sometimes repeat. Version-Release number of selected component (if applicable): How reproducible: Happens every boot. Steps to Reproduce: 1. Upgrade an FC19 system to FC20 with fedup 2. Boot 3. Cry Actual results: Boot time take over 30 minutes. Could be hours. Expected results: Should boot in seconds. Additional info:
https://lists.fedoraproject.org/pipermail/test/2014-January/119874.html after upgrade my computer : systemd.log_level=debug prevents my system to boot ! https://fedoraproject.org/wiki/Common_F20_bugs#UEFI_install_to_ms-dos_.28.27MBR.27.29_labelled_disk_fails_with_unclear_errors you use efi or bios board ? convert the partition table from MBR (ms-dos) to gpt, also could help. and from https://fedoraproject.org/wiki/Common_F20_bugs#System_fails_to_boot_after_install_using_LVM_Thin_Provisioning dracut -f , also could help. This should update Package-x-generic-16.pngdracut to the fixed version and re-generate the initramfs to include the necessary tools. Now your system should boot normally (though an SELinux relabel may run on the first boot).
While I've seen Fedora fail miserably with EFI BIOS don't think that is anything to do with this as both systems I have were working fine for a long time. I have some bind mounts in /etc/fstab and discovered commenting these seems to fix the problem. Perhaps systemd is getting confused about mount order? I will try and isolate the problem and change ticket title to reflect findings.
Found dependency on sys initial.target/start Found dependency on local-fs.target/start Breaking ordering cycle by deleting job sockets.target/start Breaking ordering cycle by deleting job firewalld.service/stop Sounds like a cyclic dep problem caused by firewalld. REassigning.
Lennart, this is the firewalld.service file: [Unit] Description=firewalld - dynamic firewall daemon Before=network.target Before=libvirtd.service Before=NetworkManager.service Conflicts=iptables.service ip6tables.service ebtables.service [Service] EnvironmentFile=-/etc/sysconfig/firewalld ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS ExecReload=/bin/kill -HUP $MAINPID # supress to log debug and error output also to /var/log/messages StandardOutput=null StandardError=null Type=dbus BusName=org.fedoraproject.FirewallD1 [Install] WantedBy=basic.target Alias=dbus-org.fedoraproject.FirewallD1.service Please explain, where firewalld is adding this cyclic dependency?
(In reply to Thomas Woerner from comment #4) > Conflicts=iptables.service ip6tables.service ebtables.service > > Please explain, where firewalld is adding this cyclic dependency? Hmm, maybe not "cyclic" ... but maybe one of the Conflicts services is active or pulled in.
I do no see, how this could be a firewalld issue. Additionally, there has been no change in the firewalld service file from F-19 to F-20 with dependencies and conflicts. This seems to either be a configuration or a systemd issue. Reassigning back to systemd.
"Found dependency on sys initial.target/start" Robin, that is not a proper unit name, can you figure out what precisely the unit name was?
Closing due to lack of response.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days