Sven Joachim wrote:
On 2010-05-29 19:12 +0200, Hugo Vanwoerkom wrote:Sven Joachim wrote:On 2010-05-27 20:26 +0200, Hugo Vanwoerkom wrote:Anybody know how to wring that out of insserv?Try the following (you don't have to be root for that): $ cp -a /etc/{init,rc?}.d /tmp/ $ /sbin/insserv -p /tmp/init.d/ And inspect the /tmp/rc?.d directories.Sven, That is exactly the trick that I was looking for. The result looks scary :-(Why? Only because it is unfamiliar? Or do you have concrete indication that the boot order is not correct? I've been using insserv for almost two years, and when I now look at the backup of /etc/rc?d which it made, _that_ looks scary to me, because the order of the symlinks and their numbers appear to be without logic, almost random.
It just is not correct. This is what the start sequence in /etc/rc6.d before using insserv looks like:
S20sendsigs [1] S30rsyslog S30urandom S31umountnfs.sh S35networking S36firehol S36ifupdown S40umountfs S60mdadm-raidS60umountroot
S90reboot and this is what it looks like after insserv: S01reboot [2] S01sendsigs S01umountfs S01umountnfs.sh S01umountroot S02rsyslog S03mdadm-raid S11ifupdown S14networking S15firehol S19urandom Reboot first before anything else?So I changed that to S90reboot but still something went wrong: the root fs was not unmounted right because at reboot he complained. So I changed it back to what it was before as in [1] by hardcoding the priorities.
Secondly insserv got invoked when I wasn't looking: by the VMware server installer :-( I had rebooted using kernel 2.6.34 from kernel.org and installed the VMware server, to see if he had problems with that new kernel version. Unbeknownst to me, he invokes insserv so dependency based boot was no longer only a test: it was a fact.
I have tried for the last 3 hours to make [2] look like [1] using the script headers, but no luck thusfar, I'd be grateful for some pointers, how does one make [2] look like [1] not by hardcoding the priorities but by using the script headers?
Even if you manage that, you are changing data that you then have to track at every upgrade.
Thanks. Hugo