#1109564 dpkg: Silent on invoking postinst abort-upgrade

Package:
dpkg
Source:
dpkg
Description:
Debian package management system
Submitter:
Lucas Nussbaum
Date:
2026-09-09 14:51:02 UTC
Severity:
normal
#1109564#5
Date:
2025-07-19 08:10:22 UTC
From:
To:
Hi,

The following fails:
- In bookworm, install bacula-director-sqlite3
- dist-upgrade to trixie

MWE:
PKG=bacula-director-sqlite3; mmdebstrap --chrooted-customize-hook="set -x ; apt -y install $PKG  && sed -e s/bookworm/trixie/ -i /etc/apt/sources.list && apt update && apt dist-upgrade -y -o Debug::pkgProblemResolver=true" bookworm /dev/null

The error is:

/var/lib/dpkg/info/bacula-common.postinst has:

I wonder if it would help to have bacula-common Depend on Pre-Depend on
systemd to help apt decide to configure it before call systemd-tmpfiles
in postinst.

More complete log:

#1109564#10
Date:
2025-07-19 08:31:16 UTC
From:
To:
                               ^^^^^^^^
                                   ^^^^^^^^
which does not invoke systemd-tmpfiles.

I wonder whats really happening. Is dpkg invoking the new postinst
(at postinst time), but putting "pre-installation" into the log message?

Or is it really invoking the postinst at preinst time?

Both look like a problem to me, and not something that Pre-Depends
should solve?

Best,
Chris

#1109564#15
Date:
2025-07-19 09:06:17 UTC
From:
To:
Chris Hofstaedtler:


FWIW, I checked the stable version of bacula-common and it has the same
story. The `systemd-tmpfiles` call only appears in the `postinst`, so
there is no way I can find that a `bacula-common.preinst` call would
trigger `systemd-tmpfiles` (the stable version of the preinst is a
subset of the testing one; I know `dpkg` says it is the `new
pre-installation script` in the log but I checked all the same).

Best regards,
Niels

#1109564#20
Date:
2025-07-19 09:40:14 UTC
From:
To:
It turns out multiple issues are involved here:

1) bacula-common's preinst fails

2) because of the preinst failure, dpkg calls abort-upgrade; in
this step systemd-tmpfiles fails. This is because libc6 did not get
upgraded yet, which is caused by #1108193

3) dpkg does not inform us that it calls abort-upgrade.

Looking at 1) closer, it appears bacula-common intentionally
defaults to breaking upgrades, by means of defaulting a debconf
question of "Do you want to continue with the upgrade?" to <No>.

I doubt this is acceptable. bacula-common already skips the question
under piuparts, which seems to me like a hack. Other automated tools
(QA or configuration management tools) are not considered.

IMO the default needs to become <Yes>.

Best,
Chris

#1109564#25
Date:
2025-07-20 07:45:37 UTC
From:
To:
clone 1109499 -1
clone 1109499 -2
retitle 1109499 bacula-common: preinst intentionally breaks upgrade
retitle -1 dpkg: Silent on invoking postinst abort-upgrade
reassign -1 dpkg
# Annoying to debug but not RC in itself
severity -1 important
retitle -2 bacula-common: Silent when aborting the upgrade
severity -2 important

thanks

On Sat, 19 Jul 2025 11:40:14 +0200 Chris Hofstaedtler <zeha@debian.org> wrote:



Thanks for debugging this.

I have cloned and reassign a bug for `dpkg` to make it announce postinst
abort-upgrade, so this becomes less of a problem in the future.
@Guillem: Concretely, the issue is we were only informed about `preinst`
failing but in reality `preinst` failed and then `postinst
abort-upgrade` failed as well. The output we saw from the maintscript
itself was from `postinst` (the preinst failure was silent, so the
postinst failure was the only output we had to go from).


@Bacula team: I have split this into two bugs for you.

  - #1109499 remains RC and is about preinst defaulting to fail on a
    non-interactive upgrade test.

  - A new bug (important) about the preinst being silent on aborting
    the upgrade. It would have helped a lot of the preinst had explicitly
    echo'ed "Aborting upgrade as requested" (or something along those
    lines), as it would have been easier to identify the root cause
    here

Thanks to Lucas and Chris for their work identifying the bug and finding
the root cause.

Best regards,
Niels

#1109564#40
Date:
2025-07-21 09:41:51 UTC
From:
To:
Hi!

I took a quick look at the involved code before departing from DebConf
yesterday, and came up with a potential fix. But afterwards when trying
to create a minimal test case for the functional test suite, I'm actually
getting the expected stacked error messages, such as:

  ,---
  (Reading database ... 1 file or directory currently installed.)
  Preparing to unpack pkg-stacked-error-1.deb ...
  dpkg: error processing archive pkg-stacked-error-1.deb (--unpack):
   new pkg-stacked-error package pre-installation script subprocess returned error exit status 1
  dpkg: error while cleaning up:
   installed pkg-stacked-error package post-installation script subprocess returned error exit status 1
  Errors were encountered while processing:
   pkg-stacked-error-1.deb
  `---

So I think I'm probably missing some step or my test case is not doing
the same as what is going on in the report. I'll try to run the provided
mmdebstrap rune with dpkg set to include maintscript debugging logging,
to try to see what's exactly going on later today.

Indeed.

Yes!

Thanks,
Guillem

#1109564#45
Date:
2025-07-23 11:31:51 UTC
From:
To:
Hi!

I tried to reproduce this problem with the original mmdebstrap recipe,
by creating a config file for dpkg with "debug 3", and there it seems
to confirm my observation that the preinst is the only thing failing
here, and that otherwise dpkg should have printed the stacked errors
for all involved failing maintscripts.

Rechecking the original log (and confirming by checking the DEBIAN/
contents from both bacula-common deb versions from bookworm and
trixie), the systemd-tmpfiles call is protected by "|| true" so
whether it fails or not, the script itself just succeeded (from dpkg's
PoV).

I guess the problem is that the original preinst fails silently, and
the subsequent failure in postinst when calling systemd-tmpfiles (which
causes no maintscript failure) is the only visible output. Although in
this case given that it was printed after the dpkg error message, it
could be understood as happening later on in some other place. But I
understand this might not always be clear/obvious.

Given that the preinst failure is not going to be recoverable with the
subsequent maintscript calls (so the package unpack will fail), and
this should not be the usual sequence of invocations, I guess the only
way to improve the current output would be to print an explicit notice
whenever a maintscript is being called for "abort-*" cases, similar to
what we already have for the "failed-*" cases. I think the increased
verbosity would then be fine as in those execution flows the package
will always end up in an action failure (where with "failed-*" the
action can actually even recover from it).

Thanks,
Guillem

#1109564#48
Date:
2026-09-09 14:19:24 UTC
From:
To:
Hi!

Bug #1109564 in package dpkg reported by you has been fixed in
the dpkg/dpkg.git Git repository. You can see the changelog below, and
you can check the diff of the fix at:

https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=af8e197d8
---
dpkg: Improve maintscript abort-* execution diagnostics

In case we end up generating error output during abort-* maintscript
invocations, that do not result in the maintscript failing, this can
become rather confusing when trying to diagnose issues.

Given that these actions will always end up with the package action
failing, and should thus not be a common occurrence, we can be more
verbose in trying to state what is going on.

Otherwise it might seem that a different maintscript action was the
cause of the error.

Closes: #1109564

#1109564#55
Date:
2026-09-09 14:49:06 UTC
From:
To:
We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1109564@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 09 Sep 2026 16:21:08 +0200
Source: dpkg
Architecture: source
Version: 1.23.11
Distribution: unstable
Urgency: medium
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Closes: 1109564
Changes:
 dpkg (1.23.11) unstable; urgency=medium
 .
   [ Guillem Jover ]
   * dpkg: Improve maintscript abort-* execution diagnostics. Closes: #1109564
   * dpkg-shlibdeps: Do not validate existence of -l option argument.
   * Code internals:
     - dpkg: Use a proper conditional instead of a ternary operator for
       f_triggers.
     - dpkg: Refactor tarobject_describe_type() into a new function.
     - dpkg-split: Refactor depot handling functions out of do_auto().
Checksums-Sha1:
 20a6dfdfae8e2cf11482deafaeb37701f7b30314 3510 dpkg_1.23.11.dsc
 0f8d21b4ba5fe575f624cf2efbe37600ce1ae418 5766064 dpkg_1.23.11.tar.xz
 8379cf3a312d2051e65684d937b73a23e2f488bf 7939 dpkg_1.23.11_amd64.buildinfo
Checksums-Sha256:
 4511c16a3bbbd3a88982408e2e5e5c471dc5f4a49eaa9b2cb93bf3e8c067fa78 3510 dpkg_1.23.11.dsc
 4baf0632157bfac430b7dc1fe8800ea0787dac91f8bb272404ae19d98e569dd3 5766064 dpkg_1.23.11.tar.xz
 d8b132ecd49233bb22b1a6dcfef6335e5e9baf955c499c88a1516a34d59605bb 7939 dpkg_1.23.11_amd64.buildinfo
Files:
 9888e3033b534a313bab4240ae0a2d49 3510 admin required dpkg_1.23.11.dsc
 9cb64292f21b40d5bcd1c041dd938854 5766064 admin required dpkg_1.23.11.tar.xz
 6d86bbd738ad177ba5d6c8620edff51d 7939 admin required dpkg_1.23.11_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

wsG7BAEBCgBvBYJqoW7RCRC5cr8+pK5Xo0cUAAAAAAAeACBzYWx0QG5vdGF0aW9u
cy5zZXF1b2lhLXBncC5vcmdc3ZZ8lV9yBtvF4PwRLl2VWeXZMFwnTNGWB1sLVe3o
7BYhBE8+dPQ2BQwQ9WlldLlyvz6krlejAABQSQ//UMd6OPkZAuYH7GWU+wBXZOhw
XQ4wgMdQydT94VJnTWt+u2+ckYsgYv3D8S+FZBxZgGYycYXAfJ7/1ZNxFU4pzhPM
uY7Ph3qg68WOgwhiwnFdO18Dn2Jm1C583gOXOYM1DabOCsxtIpuKLMX4GN3oNR3S
YLcuna00UGM8JFWIgr5NwnzgxXq3D8L206qGq6Z8iYdS7USb1rjzOmUXmlncgpPM
ESRPGc2e3yFB3Mf1RmYH53jLO/KwPc8h2dTzEkU49l5SafIGRJJdI59WHdQGu6yC
m9Sm6CM3RCC01OFoJs/i/swfYeiXk5GmwygxMbL3EENtF5sroV7DBXQoo7R5MXUr
w5GiZfD3dJ9S44VKcsjLJsmfz9SE4NuHVcKSlOZVc/ZQ7WsxQr1EBYS7ZEPhtKnD
tjnHJzIF2OqaaLN7UUKa0EO5c75SbTYmakOb3QqUygE6f5oHocDwDA+WoTsgJhO+
uSi85F07B1T1lxKC22O4jc9LkisN8PDTOwnM6XhSHWqjHXbBcYcnV+T27JogbtT1
x79kcn2OUN+08bLomS86Wd4wl1UetVU+u6JcIo6TuN6Kc4JbHfrAOcrqdwemXPxN
233M1506qM/LPg8xWns170R4xEBayU+kmlgNQFu4qYhsIci8pV57MVBN5OAlbVSl
h8HLTlpDan4WtP9QeO4=
=x583
-----END PGP SIGNATURE-----