[Andrew Moise] > I'm not entirely sure what the problem is, but the first thing I > discovered when investigating was that /etc/init.d/sysklogd is > provided by sysklogd (which was removed when it was at version > 1.4.1-11) and doesn't contain the dependency headers. It seems to > me that since that's a perfectly legitimate state for my system to > be in, insserv should be handling it by recognizing that conffiles > for packages in the "rc" state should be left out of the dependency > handling. Of course, something else entirely may be the problem > here; I'm not familiar with insserv.
I suspect the problem is the missing headers in the sysklogd script, and ignoring it is not going to work. This is a problem in the transition phase when dependency based boot sequencing is introduced. When the switch is done, no script without the header will be allowed to be inserted, and thus the obsolete scripts are safe to leave behind. Before that, we need to make sure the boot sequence is consistent and do not contain loops, and such scripts need to be removed. In this case, the problem is that sysklogd get the default header, which depend on $remote_fs and $syslog, which in this case is umountnfs and sysklogd itself. So it result in a dependency loop and there is no way to know which order the scripts should get. The reason this issue can not be ignored for removed but put purged packages, is that the set of symlinks in /etc/rcX.d/ is considered configuration, and which runlevels a given script is activated for need to be remembered until it is purged. But having a loop in one of the runlevels will make it impossible to order the scripts, and thus insserv refuse to be enabled. I recommend purging all the packages with init.d scripts that have been removed but not purged. One way to work around this issue in the transition phase would be for insserv to include an override file for all scripts that do not use a header identical to the default, to make sure scripts left behind get their proper location in the boot sequence. I'm not convinced this is a good idea, as it might hide problems and the script dependencies should be checked by someone that need the package. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
