[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. :) -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
