[oneiric] insserv reorders all init scripts

[Eduard Hasenleithner]

I'm currently testing ubuntu oneiric. When installing the third-party printer driver turboprint (http://www.turboprint.de/), all the init scripts (rc?.d) get reordered really bad. I tracked the problem down to turboprint invoking "insserv tpdaemon", which causes the init scripts to be reordered. E.g. this causes problems of several init scripts being called during reboot.

I'm not actually sure if this is a bug of insserv, or just a bug of turboprint calling insserv. But if this is the case, why is insserv still installed?

[Steve Langasek (vorlon)]

This is a severe bug in the third-party turboprint package. The insserv package is installed as a dependency of sysv-rc inherited from Debian, and is available if users *choose* to switch to dependency-based sysvinit scripts; but no package is permitted, by Debian/Ubuntu policy, to invoke insserv directly; they must use the update-rc.d policy interface, which respects the existence of the /etc/init.d/.legacy-bootordering file and avoids the use of insserv. Please report this issue to the provider of this driver package.

That said, the LSB headers in the initscripts package should all be correct for use with insserv, and insserv-provided reordering should not result in the reboot script being called before the umountroot script. Can you please show the full contents of your /etc/rc6.d directory, and attach the /etc/init.d/reboot script from your system?

[Eduard Hasenleithner (eduard-hasenleithner)]

Thanks, I will report to the package provider.

The problem should be easily reproducable on any current oneiric install with e.g.

$ sudo update-rc.d -f urandom remove
$ sudo insserv urandom

$ ls /etc/rc6.d
total 4
lrwxrwxrwx 1 root root 27 2011-07-17 01:04 K01speech-dispatcher -> ../init.d/speech-dispatcher
lrwxrwxrwx 1 root root 17 2011-07-17 01:04 K01urandom -> ../init.d/urandom
lrwxrwxrwx 1 root root 19 2011-07-17 01:04 K02bluetooth -> ../init.d/bluetooth
-rw-r--r-- 1 root root 351 2011-07-14 07:11 README
lrwxrwxrwx 1 root root 20 2011-07-17 01:04 S01networking -> ../init.d/networking
lrwxrwxrwx 1 root root 16 2011-07-17 01:04 S01reboot -> ../init.d/reboot
lrwxrwxrwx 1 root root 18 2011-07-17 01:04 S01sendsigs -> ../init.d/sendsigs
lrwxrwxrwx 1 root root 18 2011-07-17 01:04 S01umountfs -> ../init.d/umountfs
lrwxrwxrwx 1 root root 22 2011-07-17 01:04 S01umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx 1 root root 20 2011-07-17 01:04 S01umountroot -> ../init.d/umountroot
lrwxrwxrwx 1 root root 29 2011-07-17 01:04 S01unattended-upgrades -> ../init.d/unattended-upgrades

This is a output from a virtual machine I have setup today, without having "turboprint" installed at all.

[Steve Langasek (vorlon)]

Yep, confirmed this behavior in an oneiric chroot - as well as lucid and maverick.

[JKL (jkl102001)]

To fix the mess made by insserv, this is what I did:

 * figure out which package each init script belonged to
 * figure out which of those packages were installed, and which were residual
* purge the packages that were residual
* delete all the symlinks under /etc/rc*.d/
* reinstall the packages that were installed

That recreated all of the symlinks properly.

In my case, I think it was VMWare Player's installer that ran insserv, or at the very least broke all the simlinks. There is a post over on their forum describing a similar problem to this one.

http://communities.vmware.com/message/1838851

[JKL (jkl102001)]

This is not a duplicate of 858112.

With 858112, if your system is already broken (perhaps because of insserv), then doing an upgrade will create additional problems. In particular, your system may become unbootable. What you have to do to fix it is boot into safe mode and manually migrate /var/run to /run.

This bug is about the fact that insserv breaks your system in the first place. Yes, yes, packages shouldn't be using it. But it shouldn't break your system either. The way to fix this bug is to fix insserv.

These are separate bugs, with separate fixes.

Additionally, this bug was filed before 858112, so it couldn't possibly be a duplicate.

[Steve Langasek (vorlon)]

Bug #858112 is where the developers are tracking both the /run problem and the problem with insserv generally, so it's beneficial to track this bug as a duplicate of that one regardless of which was filed first.