Comment 10 for bug 1312976

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.