Bug 689861

Another thing:

When I boot I put systemd in debug mode.   I see this in the logs:

Breaking ordering cycle by deleting job dbus.socket/start

That's all I can find of why it's not starting.   I can manually start it with systemctl start dbus.service fine.    It's just not going on boot.

Looks like a systemd problem to me...

(In reply to comment #1)
> When I boot I put systemd in debug mode.   I see this in the logs:
> 
> Breaking ordering cycle by deleting job dbus.socket/start

That certainly looks relevant. Please attach the complete log to this bug.

Created attachment 487142 [details]
Boot Log with all the messages

The other thing happening is the lvm drives are not setup on boot.  They tend to get triggered like 20 minutes later and all start mounting.

I have a feeling the problems are related.

We some ordering cycles here.
I cannot find a service called "cf_hostname" in Fedora. Is that your own service?


Trying to enqueue job graphical.target/start/replace
Found ordering cycle on basic.target/start
Walked on cycle path to udev-retry.service/start
Walked on cycle path to cf_hostname.service/start
Walked on cycle path to basic.target/start
Breaking ordering cycle by deleting job udev-retry.service/start
Found ordering cycle on basic.target/start
Walked on cycle path to sockets.target/start
Walked on cycle path to dbus.socket/start
Walked on cycle path to sysinit.target/start
Walked on cycle path to systemd-random-seed-load.service/start
Walked on cycle path to local-fs.target/start
Walked on cycle path to quotacheck.service/start
Walked on cycle path to u2-CarterFamilyMedia-CarterFamilyPictures.mount/start
Walked on cycle path to network.target/start
Walked on cycle path to network.service/start
Walked on cycle path to ip6tables.service/start
Walked on cycle path to cf_hostname.service/start
Walked on cycle path to basic.target/start
Breaking ordering cycle by deleting job dbus.socket/start
Deleting job dbus.service/start as dependency of job dbus.socket/start
Found ordering cycle on basic.target/start
Walked on cycle path to sysinit.target/start
Walked on cycle path to systemd-random-seed-load.service/start
Walked on cycle path to local-fs.target/start
Walked on cycle path to quotacheck.service/start
Walked on cycle path to u2-CarterFamilyMedia-CarterFamilyPictures.mount/start
Walked on cycle path to network.target/start
Walked on cycle path to network.service/start
Walked on cycle path to ip6tables.service/start
Walked on cycle path to cf_hostname.service/start
Walked on cycle path to basic.target/start
Breaking ordering cycle by deleting job systemd-random-seed-load.service/start
Found ordering cycle on basic.target/start
Walked on cycle path to sysinit.target/start
Walked on cycle path to local-fs.target/start
Walked on cycle path to quotacheck.service/start
Walked on cycle path to u2-CarterFamilyMedia-CarterFamilyPictures.mount/start
Walked on cycle path to network.target/start
Walked on cycle path to network.service/start
Walked on cycle path to ip6tables.service/start
Walked on cycle path to cf_hostname.service/start
Walked on cycle path to basic.target/start
Breaking ordering cycle by deleting job local-fs.target/start

Any thing with cf_ is my own stuff.   Which I'm in the process of converting to systemd now.   Their just simple scripts to gather and save information to the HD for my own debugging.

You seem to have create a dependency loop here. Your service "cf_hostname" wants to be both before basic.target and after basic.target (the latter indirectly via network.service).

If systemd encounters such a loop it tries to break it by removing services from the transaction. It doesn't really know which service really matters to you and hence you might end up with stuff droipped you are really missing.

The right fix is to fix the dep loop: decide whether you want the cf_hostname run before or after basic.target. If you want it before you need to use "DefaultDependencies=no" in it and configure all deps manually.

Just wanted to add this in case someone has a similar issue.

cf_hostname is a script created prior to systemd and used SYSV (at least I think that's what it's called)

So it was to run based on the 0-99 priority.   If this is causing a loop then other legacy scripts can fall into the same problem.

To fix I just converted to systemd and set the proper dependencies... ie I only need the cf_hostname check to run before firstboot.

Seeing quotacheck.service and udev-retry.service in the cycles makes me believe that this problem is probably gone with the current systemd and udev versions.
(udev-retry is gone and a known bug where quotacheck was added when it should not has been fixed.)

(In reply to comment #8)
> Just wanted to add this in case someone has a similar issue.
> 
> cf_hostname is a script created prior to systemd and used SYSV (at least I
> think that's what it's called)
> 
> So it was to run based on the 0-99 priority.   If this is causing a loop then
> other legacy scripts can fall into the same problem.

Yupp, systemd is a bit more strict here, we actually try to honour the ordering requests... This sometimes brings us into trouble...