On Sat, Jul 19, 2025 at 10:10:22AM +0200, Lucas Nussbaum wrote:

The error is:

Preparing to unpack .../bacula-common_15.0.3-3_amd64.deb ...
dpkg: error processing archive /var/cache/apt/archives/bacula-common_15.0.3-3_amd64.deb (--unpack):
new bacula-common package pre-installation script subprocess returned error exit status 1

^^^^^^^^

systemd-tmpfiles: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by /lib/x86_64-linux-gnu/libkmod.so.2)

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

^^^^^^^^

# Automatically added by dh_installtmpfiles/13.24.2
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
if [ -x "$(command -v systemd-tmpfiles)" ]; then
systemd-tmpfiles ${DPKG_ROOT:+--root="$DPKG_ROOT"} --create bacula.conf || true
fi
fi
# End automatically added section

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.

The preinst script should be this: https://binarycontrol.debian.net/cache/unstable/bacula-common/preinst
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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jul 19, 2025 at 11:06:17AM +0200, Niels Thykier wrote:

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`

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

retitle 1109499 bacula-common: preinst intentionally aborts unattended upgrade of bacula-director

Hi,

first off: let's be clear as to what is happening. We aren't
"intentionally break"ing upgrades.


Paul Gevers <[email protected]> writes:

On Sun, 20 Jul 2025 12:27:53 +0200 Niels Thykier <[email protected]> wrote:

Perharps debian-devel or other people that would be in similar
situations can help. Concretely, I suspect the postgres/mariaDB
maintainers would have been in a similar situation at some point (I
think PostgreSQL has a yearly bump of data base format). Personally,
I would probably reach out to the PostgreSQL maintainers / check the
PG packaging.

I think the following scenarios are relevant:

1) The database is on the same machine as bacula-director.

a) We are running a production machine.
b) We are running some automated QA tool.

2) The database is not on the same machine as bacula-director.

I don't think there is any QA tool testing this scenario.


I see the following ways forward:

A) Keep the status quo

B) Default to "Yes" (applies to all scenarios)

If we switch the default for all scenarios to "Yes, go ahead with the
update", I fully expect to receive bug reports about failed upgrades
and I can imagine the frustration of people with big installations
that only notice hours (or days) later that the upgrade broke and they
need to do a restore that can then take another few hours, just to get
to the point where they started from.

If the release team says this is the way to go, so be it. However, I
note that so far this didn't happen.

C) Try to check space on localhost (scenario 1)

Check if the database server is "localhost", then try to determine if
there is enough space and if yes, go ahead with the upgrade. If there
doesn't seem to be enough space, warn the user and suggest to abort
or continue.

If the database server is not "localhost", warn the user and suggest
to abort or continue (scenario 2).

Automatically determining free space is probably tricky with several
edge cases, especially when interesting mount points exist.

D) Add exceptions for more QA tools (scenario 1b)

Maybe we can reduce the amount of people running into the scenario
where this is needed by giving sound upgrade instructions?

Sven has submitted an addition to the release notes:

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/290

Is the upgrade handled by dbconfig-common? I recall that will at least
dump the database before trying the upgrade and notify the user of
that in case of failures.

Yes, it is handled by dbconfig-common (if the user didn't shoot
themselves in the foot by opting out of all or part of it, like we
sometimes see).

Regards

Carsten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

my mail from last week didn't receive any feedback.

Let's look at this another way: I think this boils down to the question
what kind of support we will need to give after the release. My take is
that it will be either:

a) users where the upgrade didn't go through because they didn't affirm
that their systems are fit for the upgrade of the bacula database
(very easy and quick to fix).

b) users with a broken bacula database (hard to fix, probably annoying
or stressful and time-consuming for the user).

I very much prefer a). If I don't hear anything to the contrary from the release team, I'll downgrade the bug in a few days.

Regards

Carsten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 28, 2025 at 11:27:17AM +0200, Carsten Leonhardt wrote:

Hi,

my mail from last week didn't receive any feedback.

Let's look at this another way: I think this boils down to the question
what kind of support we will need to give after the release. My take is
that it will be either:

a) users where the upgrade didn't go through because they didn't affirm
that their systems are fit for the upgrade of the bacula database
(very easy and quick to fix).

Note that this is only true, _if_ the upgrade is aborted before
anything else was done by APT. If APT started installing packages,
and there are ordering issues, users can very well end up in a
situation that is very hard to recover from.

One example that was found is #1108193 and fixed.
Another is #1109119, with currently no resolution in sight.
As such aborting upgrades seems very risky this time.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jul 28, 2025 at 12:12:55PM +0200, Carsten Leonhardt wrote:

...
should we recommend upgrading to bacula from backports before the dist-upgrade in the release notes? That will perform the database
upgrade and seems like an easy workaround.

no, backports shouldn't become a requirement for a regular upgrade from
one release to the next release. It would also not make a difference
with the problem at hand that the user is forced to answer (or preseed
a debconf answer) for something that is not necessary.


On Mon, Jul 21, 2025 at 06:44:17PM +0200, Carsten Leonhardt wrote:

...
B) Default to "Yes" (applies to all scenarios)

If we switch the default for all scenarios to "Yes, go ahead with the
update", I fully expect to receive bug reports about failed upgrades
and I can imagine the frustration of people with big installations
that only notice hours (or days) later that the upgrade broke and they
need to do a restore that can then take another few hours, just to get
to the point where they started from.
...

Is it true that they would "only notice hours (or days) later"?

The expected error handling would be:
1. bacula-director-$db.postint fails, aborting the upgrade with a clear
error message for the administrator
2. administrator creates required space
3. attempting again to upgrade the package is successful and results in
a correctly upgraded database

What actually matters is that this error handling works,
since some users will always hit this problem no matter
how often and how annoyingly you informed them.


Regarding bacula-common.preinst, it is much better for our users to read
the release notes once instead of having to deal with release notes in
the form of dozens of debconf questions on every single machine being
upgraded.

debconf is for configuring packages, not for forcing information on users.

It seems something has already been added to the release notes: https://www.debian.org/releases/trixie/release-notes/issues.html#bacula-director-database-schema-update-needs-large-amounts-of-disk-space-and-time

Release notes and NEWS.Debian are for informing users, you already have
both of these now.

Regards

Carsten

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Adrian,

Adrian Bunk <[email protected]> writes:

On Mon, Jul 28, 2025 at 12:12:55PM +0200, Carsten Leonhardt wrote:

...
should we recommend upgrading to bacula from backports before the
dist-upgrade in the release notes? That will perform the database
upgrade and seems like an easy workaround.

no, backports shouldn't become a requirement for a regular upgrade from
one release to the next release. It would also not make a difference
with the problem at hand that the user is forced to answer (or preseed
a debconf answer) for something that is not necessary.

Note that I didn't write "requirement". The idea here was to *recommend* decoupling the bacula database upgrade from the debian release
upgrade. That was an idea to address Chris' concers upthread.

On Mon, Jul 21, 2025 at 06:44:17PM +0200, Carsten Leonhardt wrote:

...
B) Default to "Yes" (applies to all scenarios)

If we switch the default for all scenarios to "Yes, go ahead with the
update", I fully expect to receive bug reports about failed upgrades
and I can imagine the frustration of people with big installations
that only notice hours (or days) later that the upgrade broke and they
need to do a restore that can then take another few hours, just to get
to the point where they started from.
...

Is it true that they would "only notice hours (or days) later"?

Yes, if the database they have is big enough. See https://alioth-lists.debian.net/pipermail/pkg-bacula-devel/2024-February/003373.html

The expected error handling would be:
1. bacula-director-$db.postint fails, aborting the upgrade with a clear
error message for the administrator
2. administrator creates required space
3. attempting again to upgrade the package is successful and results in
a correctly upgraded database

What actually matters is that this error handling works,
since some users will always hit this problem no matter
how often and how annoyingly you informed them.

Don't forget that dbconfig will already have altered the database. Just
adding space and running the upgrade again will fail.

Let's say the postinst fails. A recovery to the previous state of the
bacula database is necessary to get to the point where you can retry the upgrade. In the case linked above, a dump+restore takes 9 hours.

It's also possible that the upgrade doesn't fail at all, but just hangs
with the database server waiting for more space to appear. I've seen
that happen with MariaDB/MySQL in other contexts, and killing the
database server process can then leave the database in an inconsistent
state that necessitates starting the database server in a recovery mode
and try to fix things, which isn't fun at all.

Regarding bacula-common.preinst, it is much better for our users to read
the release notes once instead of having to deal with release notes in
the form of dozens of debconf questions on every single machine being upgraded.

debconf is for configuring packages, not for forcing information on users.

It seems something has already been added to the release notes: https://www.debian.org/releases/trixie/release-notes/issues.html#bacula-director-database-schema-update-needs-large-amounts-of-disk-space-and-time

Release notes and NEWS.Debian are for informing users, you already have
both of these now.

We ask for confirmation that the upgrade is possible, I think that's not "forcing information on users".

Regards

Carsten

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jul 20, 2025 at 12:44:21PM +0200, Paul Gevers wrote:

...
The situation for MariaDB warranted documentation in the Release Notes:

https://www.debian.org/releases/trixie/release-notes/issues.html#mariadb-major-version-upgrades-only-work-reliably-after-a-clean-shutdown

Maybe we can reduce the amount of people running into the scenario where
this is needed by giving sound upgrade instructions?
...

I would dispute that what you linked for MariaDB is a sound upgrade instruction.

If the user followed this instruction, and if during the upgrade bacula-director-mysql ends up getting configured before mariadb-server,
then the postinst of bacula-director will try to upgrade its schema
in a database that is not running.

Paul

cu
Adrian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)