On Fri, Oct 31, 2014 at 02:15:45PM +0100, Michal Schmidt wrote: > Maybe you already had an ordering cycle on Oct 26, but different units > were chosen for deletion when breaking the cycle, and by luck it had > fewer directly observable consequences. > Could you check older logs for ordering cycles?
Yeah, I was just doing that, and there's no ordering cycle logged before late last night (e.g. the ill-fated reboot). That said, as you expected, disabling nfs-client.target does make the system boot successfully. I'm still getting a problem with dev-mqueue.mount, though: Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway. Oct 31 09:19:46 ubik mount[4484]: mount: mount point /dev/mqueue does not exist Oct 31 09:19:46 ubik systemd[1]: dev-mqueue.mount mount process exited, code=exited status=32 Oct 31 09:19:46 ubik systemd[1]: Failed to mount POSIX Message Queue File System. On a related but different note — is there a way to detect potential ordering cycles from a set of RPMs on disk (possibly installed in a chroot or something) _without_ actually booting? Maybe we could add a taskotron check for that for packages with changes to systemd unit files. (I realize that what is enabled on people's systems will have an impact, but we could check against a set of defaults at least.) -- Matthew Miller <mat...@fedoraproject.org> Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
