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 -- 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/87fx1978yh....@turtle.gmx.de
