Description of problem: On boot I see: Oct 27 15:20:00 vmf21.cora.nwra.com systemd[1]: Job timers.target/start deleted to break ordering cycle starting with basic.target/start Version-Release number of selected component (if applicable): systemd-216-5.fc21.x86_64 systemd-216-11.fc22.x86_64
'systemd-analyze dump' and 'journalctl -b' please.
Created attachment 951530 [details] systemd-analyze dump - gzipped
Created attachment 951531 [details] journalctl -b - gzipped
That's strange. In the dump, timers.target is before basic.target and everything seems alright.
From /usr/lib/systemd/systemd --test --system | grep -Fi cycle: Found ordering cycle on basic.target/start Found dependency on timers.target/start Found dependency on mandb.timer/start Found dependency on time-sync.target/start Found dependency on ntpdate.service/start Found dependency on network.target/start Found dependency on NetworkManager-wait-online.service/start Found dependency on basic.target/start Breaking ordering cycle by deleting job timers.target/start Job timers.target/start deleted to break ordering cycle starting with basic.target/start Does that help?
http://cgit.freedesktop.org/systemd/systemd/commit/?id=919699ec301ea507e might be related.
Made that change, but still the same.
OK, so the problem is that mandb.timer is Persistent=yes, which means systemd wants to have time synchronized before starting it, but also adds it implicitly to timers.target and thus to start it during early boot. Together this is impossible. An easy (as systemd maintainer) solution would be to blame mandb, since they introduce the loop, strictly speaking. But current semantics just wrong and easy to get wrong, even for Persistent=no timers, since the dependency on timers.target is added automatically. Looking at all the timer units available in F21, apart from systemd-readahead-done.timer and mdadm-last-resort@.timer, both of which specify DefaultDependencies=no, so are not part of timers.target anyway, none of them actually want to be part of early boot. So I'm inclined to just let timers.target lose the timing relationship with basic.target. Patch sent to the mailing list ('unit: do not order timers.target before basic.target').
Also http://cgit.freedesktop.org/systemd/systemd/commit/?id=14fe721b5f.
kmod-18-4.fc21,systemd-216-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-7.fc21
kmod-18-4.fc21,systemd-216-9.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-9.fc21
kmod-18-4.fc21,systemd-216-10.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/kmod-18-4.fc21,systemd-216-10.fc21
Package kmod-18-4.fc21, systemd-216-10.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kmod-18-4.fc21 systemd-216-10.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14307/kmod-18-4.fc21,systemd-216-10.fc21 then log in and leave karma (feedback).
Package kmod-18-4.fc21, systemd-216-11.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kmod-18-4.fc21 systemd-216-11.fc21' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-14307/kmod-18-4.fc21,systemd-216-11.fc21 then log in and leave karma (feedback).
kmod-18-4.fc21, systemd-216-11.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.