On 2010-05-30 16:07 +0200, Hugo Vanwoerkom wrote:
Sven Joachim wrote:
On 2010-05-29 19:12 +0200, Hugo Vanwoerkom wrote:
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
The fact that you actually have any Snn* links in /etc/rc6.d is an
artifact of the old boot system with fixed numbers. When you migrate to
dependency-based boot system, these will be converted to Knn* links (the
initscripts package special-cases runlevels 0 and 6, calling all scripts
with a stop argument, even for "start" links).
and this is what it looks like after insserv:
S01reboot [2]
S01sendsigs
S01umountfs
S01umountnfs.sh
S01umountroot
S02rsyslog
S03mdadm-raid
S11ifupdown
S14networking
S15firehol
S19urandom
This is indeed not correct, but the conversion will turn these into Knn*
links first, and then you'll get a very different order. Here's mine
for reference:
,----
| $ ls -1 /etc/rc6.d
| K01alsa-utils
| K01anacron
| K01atd
| K01gpm
| K01lpd
| K01nfs-kernel-server
| K01postfix
| K01stop-readahead-fedora
| K01timidity
| K01urandom
| K01xdm
| K02bind9
| K03sendsigs
| K04rsyslog
| K05umountnfs.sh
| K06nfs-common
| K06portmap
| K07hwclock.sh
| K07networking
| K08ifupdown
| K09umountfs
| K10umountroot
| K11reboot
| README
`----
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'm sorry that this happened to you.
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?
By running "dpkg-reconfigure sysv-rc". Note that this will convert S*
links in runlevels 0 and 6 to K* links, but as I tried to explain, this
is what you want.
Even if you manage that, you are changing data that you then have to
track at every upgrade.
You don't have to do that, insserv does it for you.