Hi! On Thu, 2018-10-11 at 19:56:46 +0200, Holger Levsen wrote: > Package: dpkg > Version: 1.18.25 > Severity: important
> on June 28th 2018 was the last successful test of > https://jenkins.debian.net/job/chroot-installation_stretch_install_education-mathematics_upgrade_to_buster/ > which tests the installation of the education-mathmatics meta-package on > a clean stretch install (in a chroot) and then upgrades this chroot to > buster. Since July 7th 2018 this test is failing... > > As I read > https://jenkins.debian.net/job/chroot-installation_stretch_install_education-mathematics_upgrade_to_buster/35/consoleFull > the upgrade is done using dpkg 1.8.25, however I'm not fully sure the > bug is coming from dpkg... > > The failure is (happening when upgrading packages to buster): > > Setting up kalgebra (4:17.08.3-2) ... > dpkg: ../../src/packages.c:245: process_queue: Assertion `dependtry <= 4' > failed. > E: Sub-process /usr/bin/dpkg exited unexpectedly > > Feedback much appreciated as I'm lost here. Also maybe this bug should > have severity 'serious' as it breaks upgrades to Buster?!? Just in case this is helpful in the future, I've reproduced this now, by using in addition: ,--- /etc/dpkg/dpkg.cfg.d/00db-git --- post-invoke "cd /var/lib/dpkg && git add -A && git commit -m 'Committing dpkg db to git' || true" `--- ,--- /etc/dpkg/dpkg.cfg.d/01debug --- debug 77777 `--- And an initial: $ cd /var/lib/dpkg $ git init $ git add -A $ git commit -m 'Initial import' Then, first, there's a bug (normal probably) in dpkg with the assert/internal-error, which should be a proper error message, this needs to be fixed, and I think there's one or two bugs about just that. Then, the current reporting in the buster internal error message still sucks, so I'll try to improve that too, to: - Print the current processed package and in the ones in the queue. - Print the command-line options used to invoke dpkg, or at least the state of the --[no-]triggers option, and whether we were called with a --pending or an explicit list of packages. - Recommend running «dpkg --audit» and attaching that too, while reporting the problem. But in any case the real cause for this seem to be just the usual trigger cycle problem (serious, for the offending cycle introducer), that gets abandoned and resets the state of dbus, which is never tried to get configure again, as specified. The trigger happens with this: ,--- […] D000001: process queue pkg gconf2:amd64 queue.len 168 progress 53, try 2 D010000: trigproc gconf2:amd64 D010000: check_triggers_cycle pnow=gconf2:amd64 D020000: tortoise_not_in_hare pnow=gconf2 tortoise=dbus D020000: tortoise_not_in_hare pnow=gconf2 tortoise=dbus tortoisetrig=/etc/dbus-1/system.d D040000: tortoise_not_in_hare pnow=gconf2 tortoise=dbus tortoisetrig=/etc/dbus-1/system.d haretrig=/etc/dbus-1/system.d D020000: tortoise_not_in_hare pnow=gconf2 tortoise=shared-mime-info D020000: tortoise_not_in_hare pnow=gconf2 tortoise=shared-mime-info tortoisetrig=/usr/share/mime/packages D040000: tortoise_not_in_hare pnow=gconf2 tortoise=shared-mime-info tortoisetrig=/usr/share/mime/packages haretrig=/usr/share/mime/packages D020000: tortoise_not_in_hare pnow=gconf2 tortoise=libvlc-bin:amd64 D020000: tortoise_not_in_hare pnow=gconf2 tortoise=libvlc-bin:amd64 tortoisetrig=/usr/lib/x86_64-linux-gnu/vlc/plugins D040000: tortoise_not_in_hare pnow=gconf2 tortoise=libvlc-bin:amd64 tortoisetrig=/usr/lib/x86_64-linux-gnu/vlc/plugins haretrig=/usr/lib/x86_64-linux-gnu/vlc/plugins D020000: tortoise_not_in_hare pnow=gconf2 tortoise=libc-bin D020000: tortoise_not_in_hare pnow=gconf2 tortoise=libc-bin tortoisetrig=ldconfig D040000: tortoise_not_in_hare pnow=gconf2 tortoise=libc-bin tortoisetrig=ldconfig haretrig=ldconfig D020000: tortoise_not_in_hare pnow=gconf2 tortoise=dictionaries-common D020000: tortoise_not_in_hare pnow=gconf2 tortoise=dictionaries-common tortoisetrig=aspell-autobuildhash D040000: tortoise_not_in_hare pnow=gconf2 tortoise=dictionaries-common tortoisetrig=aspell-autobuildhash haretrig=aspell-autobuildhash D020000: tortoise_not_in_hare pnow=gconf2 tortoise=gconf2 D020000: tortoise_not_in_hare pnow=gconf2 tortoise=gconf2 tortoisetrig=/usr/share/gconf/schemas D040000: tortoise_not_in_hare pnow=gconf2 tortoise=gconf2 tortoisetrig=/usr/share/gconf/schemas haretrig=/usr/share/gconf/schemas dpkg: cycle found while processing triggers: chain of packages whose triggers are or may be responsible: shared-mime-info -> gconf2 packages' pending triggers which are or may be unresolvable: dbus: /etc/dbus-1/system.d shared-mime-info: /usr/share/mime/packages libvlc-bin:amd64: /usr/lib/x86_64-linux-gnu/vlc/plugins libc-bin: ldconfig dictionaries-common: aspell-autobuildhash gconf2: /usr/share/gconf/schemas D010000: check_triggers_cycle pnow=gconf2:amd64 giveup=dbus:amd64 dpkg: error processing package dbus (--configure): triggers looping, abandoned […] `--- I see the following await triggers in the system: ,--- triggers/File:/etc/sgml sgml-base triggers/File:/usr/share/sgml sgml-base triggers/File:/usr/share/xml sgml-base triggers/File:/usr/share/glib-2.0/schemas libglib2.0-0:amd64 triggers/File:/usr/share/gconf/defaults gconf2 triggers/File:/usr/share/gconf/mandatory gconf2 triggers/File:/usr/share/gconf/schemas gconf2 triggers/ldconfig:libc-bin triggers/update-ca-certificates:ca-certificates triggers/update-ca-certificates-fresh:ca-certificates triggers/update-sgmlcatalog:sgml-base `--- After some quick digging, I'm not able to spot any obvious cycle here, either I'm missing it, or perhaps a required package to resolve one of the cyles is not in the processing queue. I might try to improve the «triggers looping, abandoned» error to perhaps also print the processing queue contents with their current states. The problematic state just before the assert is this: ,--- dpkg --audit --- The following packages have been unpacked but not yet configured. They must be configured using dpkg --configure or the configure menu option in dselect for them to work: avahi-daemon Avahi mDNS/DNS-SD daemon libnss-mdns:amd64 NSS module for Multicast DNS name resolution The following packages are only half configured, probably due to problems configuring them the first time. The configuration should be retried using dpkg --configure <package> or the configure menu option in dselect: dbus simple interprocess messaging system (daemon and utilitie The following packages have been triggered, but the trigger processing has not yet been done. Trigger processing can be requested using dselect or dpkg --configure --pending (or dpkg --triggers-only): dictionaries-common spelling dictionaries - common utilities libc-bin GNU C Library: Binaries libvlc-bin:amd64 tools for VLC's base library tex-common common infrastructure for building and installing TeX `--- From the debug log, we also see that dpkg got stuck with avahi-daemon and libnss-mdns:amd64 in the queue. libnss-mdns:amd64 depends on avahi-daemon: ,--- […] D000040: checking dependencies of libnss-mdns:amd64 (- <none>) D000400: checking group ... D000400: checking possibility -> avahi-daemon D000400: checking non-provided pkg avahi-daemon:amd64 D000400: unpacked/halfconfigured, defer D000400: found 1 D000400: found 1 matched 0 possfixbytrig - […] D000040: ok 1 msgs >><< `--- And avahi-daemon depend on dbus: ,--- […] D000040: checking dependencies of avahi-daemon:amd64 (- <none>) […] D000400: checking group ... D000400: checking possibility -> dbus D000400: checking non-provided pkg dbus:amd64 D000400: unpacked/halfconfigured, defer D000400: found 1 D000400: found 1 matched 0 possfixbytrig - […] D000040: ok 1 msgs >><< `--- And dbus as seen from «dpkg --audit» is half-configured, and was not in the processing queue, so dpkg was unable to make progress. After the assert/internerr, if you just run «dpkg --configure --pending» dpkg will be able to make normal progress. Thanks, Guillem
