Finally there are two dependency cycles which we need to fix:
Found ordering cycle on basic.target/start
Found dependency on sysinit.target/start
Found dependency on apparmor.service/start
Found dependency on remote-fs.target/start
Found dependency on remote-fs-pre.target/start
Found dependency on nfs-client.target/start
Found dependency on rpc-statd-notify.service/start
Found dependency on nfs-server.service/start
Found dependency on rpc-svcgssd.service/start
Found dependency on basic.target/start
Breaking ordering cycle by deleting job apparmor.service/start
Job apparmor.service/start deleted to break ordering cycle starting with basic.target/start
Found ordering cycle on basic.target/start
Found dependency on sysinit.target/start
Found dependency on console-setup.service/start
Found dependency on remote-fs.target/start
Found dependency on remote-fs-pre.target/start
Found dependency on nfs-client.target/start
Found dependency on rpc-statd-notify.service/start
Found dependency on nfs-server.service/start
Found dependency on rpc-svcgssd.service/start
Found dependency on basic.target/start
Breaking ordering cycle by deleting job console-setup.service/start
Job console-setup.service/start deleted to break ordering cycle starting with basic.target/start
This is because these two don't have native systemd units, and their init.d script depends on $remote_fs. But remote-fs.target requires quite a lot (networking, dbus, perhaps NetworkManager, etc.), and we do want to protect those with apparmor. Also, apparmor only uses files in /, so $local_fs is sufficient even for the hypothetical "/usr on NFS" case.
That's less true for console-setup: This does use files from /usr; however, as we've never officially supported /usr on NFS, and nobody ever tested that under upstart, I'm very much inclined to just fix its init.d dependency to $local_fs, too.
Finally there are two dependency cycles which we need to fix:
Found ordering cycle on basic.target/start target/ start service/ start fs.target/ start fs-pre. target/ start target/ start notify. service/ start service/ start service/ start service/ start service/ start deleted to break ordering cycle starting with basic.target/start
Found dependency on sysinit.
Found dependency on apparmor.
Found dependency on remote-
Found dependency on remote-
Found dependency on nfs-client.
Found dependency on rpc-statd-
Found dependency on nfs-server.
Found dependency on rpc-svcgssd.
Found dependency on basic.target/start
Breaking ordering cycle by deleting job apparmor.
Job apparmor.
Found ordering cycle on basic.target/start target/ start setup.service/ start fs.target/ start fs-pre. target/ start target/ start notify. service/ start service/ start service/ start setup.service/ start setup.service/ start deleted to break ordering cycle starting with basic.target/start
Found dependency on sysinit.
Found dependency on console-
Found dependency on remote-
Found dependency on remote-
Found dependency on nfs-client.
Found dependency on rpc-statd-
Found dependency on nfs-server.
Found dependency on rpc-svcgssd.
Found dependency on basic.target/start
Breaking ordering cycle by deleting job console-
Job console-
This is because these two don't have native systemd units, and their init.d script depends on $remote_fs. But remote-fs.target requires quite a lot (networking, dbus, perhaps NetworkManager, etc.), and we do want to protect those with apparmor. Also, apparmor only uses files in /, so $local_fs is sufficient even for the hypothetical "/usr on NFS" case.
That's less true for console-setup: This does use files from /usr; however, as we've never officially supported /usr on NFS, and nobody ever tested that under upstart, I'm very much inclined to just fix its init.d dependency to $local_fs, too.