Bug#726027: Required-Start: $remote_fs for rcS type services (early boot) can lead to dependency loops

[Marc Glisse]

On Mon, 28 Jul 2014, Michael Biebl wrote:

> Am 28.07.2014 15:53, schrieb Marc Glisse:
>> "makes unrelated software on the system (or the whole system) break",
>> pretty much what I am seeing here. The recent upgrades pulled in systemd
>> (it is very hard to avoid currently) and made the system unbootable. The
>> workaround I found was to boot in debug mode, run
>
> A loop does not mean unbootable (therefore adjusting the severity).

Actually, I was hasty: it does boot, and I can even login as root, though 
I have to wait a number of timeouts, I only get the tty1, X fails to 
start, etc. And most importantly (I didn't have physical access when the 
issue first happened) the network doesn't work at all. 
"/etc/init.d/network-manager restart" hangs for a while then annouces it 
failed.

>> "/etc/init.d/network-manager start" then exit so normal boot would resume.
>>
>> Looking through messages, I noticed that systemd was breaking a loop by
>> disabling (at least) rpcbind and nfs-common and eventually found this
>> bug. Following the instructions, I sed s/remote_fs/local_fs/ for all the
>> Required-Start: in /etc/rcS.d, and the next boot seems to have worked
>> just fine.
>
> dependency loops can exist

Really, that's not always a bug?

> an systemd removes services from such loops
> automatically to break those loops.
>
> In your case that doesn't seem to have worked (or there is maybe another
> issue).
>
> Could you please undo the changes you made to your rcS services,
> enabled the debug shell (systemctl enable debug-shell.service),
> boot with systemd.log_level=debug, and on next reboot, switch to tty9 to
> examine the output.
>
> The output of "systemctl list-jobs" and "journalctl -alb" would be
> helpful for a start.

The first only listed:
497 systemd-logind.service start running

The second is:
http://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/systemd

It seems that the NetworkManager service is the only one really failing, 
maybe because of policykit.
(you can probably ignore the ldap messages, they have always been there)
I ran "/etc/init.d/gdm3 stop" before so it wouldn't try to switch tty 
everytime an attempt to start X failed.

-- 
Marc Glisse