[Pkg-sysvinit-devel] Bug#706877: insserv: breaks dist-upgrade by installing before packages fix their init scripts
lucas at debian.org
Thu Nov 6 08:08:25 UTC 2014
On 20/10/13 at 09:33 +0200, Petter Reinholdtsen wrote:
> [Jamin W. Collins]
> > It may be bogus or incomplete boot script ordering information, but it
> > previously worked, keep that in mind. One does not expect a Debian
> > dist-upgrade from one stable release to another to result in a
> > non-functional system.
> Sure. But the fact that the ordering was not broken when the
> dependencies was ignored do not really matter much. 'ignoring ordering
> loops' is another way to say 'generate incorrect boot sequence', which
> might result in a non-bootable system. So there is no safe way to
> continue when the boot ordering can not be trusted, and update-rc.d
> refuse to upgrade more packages when this happen as a safe-guard against
> silently breaking the boot (which would only be discovered the next time
> the machine is booted, instead of when the upgrade happen).
> > The former effectively left me locked out of my systems. I had to
> > reboot every one of them to a single user root session to fix them as
> > my user existed only in LDAP and then unrelated init scripts caused
> > the upgrade to abort in such a way that my user could no longer be
> > validated for sudo. Had the upgrade proceeded, the system would have
> > been in complete working order (AFAICT).
> Did you run 'sudo apt-get dist-upgrade', and was unable to run a new
> sudo command when the upgrade failed? Perhaps a safer approach is to
> use 'sudo -i' and then run 'apt-get dist-upgrade' with a root shell to
> make sure you can recover when something go wrong?
> Anyway, I am positive to try to figure out way to avoid breaking systems
> where upgrading packages in a different order would work, but do not
> know which packages have incorrect dependencies in earlier versions
> leading to dependency loops and thus do not know how to do it. :)
Is this bug still a problem for wheezy->jessie upgrades?
One could argue that all packages with problematic dependencies could
likely have been fixed during the jessie cycle.
Looking at bugs mentioned in this bug log:
#651037: a duplicate of #650995; fixed in wheezy
#680223: caused by munin-node, fixed in wheezy
#695751: discussion on dependencies on packages themselves depending on
$all, either implicitely or explicitely (because they would
have no LSB headers). There are only a few packages remaining
with missing LSB headers, and none of them seem likely to be
depended. There are more that depend explicitely on $all
(lintian has a check for that), and maybe they should be fixed,
but again, none of them seem likely to be depended on, except
maybe cloud-init. So I believe that in practice, this problem is
not so severe.
#589238: several (old) reports of dependency loops. (last activity in
Given that this bug was present (unfixed) in wheezy, and the situation
can only have improved since then, I think that this bug should be
More information about the Pkg-sysvinit-devel