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-raid
S60umountroot
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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/httreq$qa...@dough.gmane.org
