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:
^^^^^^^^
^^^^^^^^
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
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
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
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
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
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