I can't do the comparison on my workstation as I already ran insserv a few weeks ago manually (without this branch and the init.d scripts added back); I also didn't notice any problems since then.
I did a few reboot and powerdown/boot tests without obvious failures, but it seems prudent to look into the details as many of the scripts' effects are not immediately obvious. I looked at the differences in above pastebins:
= rc[2345].d =
The order changed a bit, but only for scripts which don't depend on each other. insserv tends to sort the scripts without/with fewer dependencies like dns-clean first, which makes sense. rc.local is still correctly the last item.
= rc[06].d =
This looks a bit odd. In the original "legacy" ordering we had
won't that change the semantics? (being called with "stop" instead of "start", etc.)
= rc1.d =
Looks fine
= rcS.d =
As expected we now have the ~ 11 scripts there which got introduced merely for ordering reason, they should be no-ops. Our 4 original links are still there in a reasonable order.
So we should investigate the S → K change for 0/6, otherwise this looks good.
I built and installed this into a relatively clean utopic VM.
/rc/rc?.d/ before: http:// paste.ubuntu. com/7519546/ paste.ubuntu. com/7519547/
/rc/rc?.d/ after: http://
I can't do the comparison on my workstation as I already ran insserv a few weeks ago manually (without this branch and the init.d scripts added back); I also didn't notice any problems since then.
I did a few reboot and powerdown/boot tests without obvious failures, but it seems prudent to look into the details as many of the scripts' effects are not immediately obvious. I looked at the differences in above pastebins:
= rc[2345].d =
The order changed a bit, but only for scripts which don't depend on each other. insserv tends to sort the scripts without/with fewer dependencies like dns-clean first, which makes sense. rc.local is still correctly the last item.
= rc[06].d =
This looks a bit odd. In the original "legacy" ordering we had
lrwxrwxrwx 1 root root 18 Mej 25 13:20 S20sendsigs -> ../init.d/sendsigs d/umountnfs. sh d/umountroot
lrwxrwxrwx 1 root root 17 Mej 25 13:20 S30urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root 22 Mej 25 13:20 S31umountnfs.sh -> ../init.
lrwxrwxrwx 1 root root 18 Mej 25 13:20 S40umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root 20 Mej 25 13:20 S60umountroot -> ../init.
lrwxrwxrwx 1 root root 14 Mej 25 13:20 S90halt -> ../init.d/halt
but these got turned into "K" links like
lrwxrwxrwx 1 root root 20 Mej 26 09:48 K01kerneloops -> ../init. d/kerneloops dispatcher -> ../init.d/speech
lrwxrwxrwx 1 root root 15 Mej 26 09:48 K01rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root 27 Mej 26 09:48 K01speech-
-dispatcher
won't that change the semantics? (being called with "stop" instead of "start", etc.)
= rc1.d =
Looks fine
= rcS.d =
As expected we now have the ~ 11 scripts there which got introduced merely for ordering reason, they should be no-ops. Our 4 original links are still there in a reasonable order.
So we should investigate the S → K change for 0/6, otherwise this looks good.