Re: Dependency based boot sequence conversion
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.
Sven
Reply to: