Re: possibly problem with rawhide (systemd-217?): "Found ordering cycle on basic.target/start"
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
<mattdm(a)fedoraproject.org>
Fedora Project Leader