possibly problem with rawhide (systemd-217?): "Found ordering cycle on basic.target/start"
mattdm at fedoraproject.org
Fri Oct 31 13:30:35 UTC 2014
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
Oct 31 09:19:46 ubik systemd: dev-mqueue.mount: Directory /dev/mqueue to mount over is not empty, mounting anyway.
Oct 31 09:19:46 ubik mount: mount: mount point /dev/mqueue does not exist
Oct 31 09:19:46 ubik systemd: dev-mqueue.mount mount process exited, code=exited status=32
Oct 31 09:19:46 ubik systemd: 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.)
<mattdm at fedoraproject.org>
Fedora Project Leader
More information about the devel