Package: bacula-director-sqlite3
Version: 15.0.3-3
Severity: serious

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:

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.

More complete log:

(Reading database ... 11336 files and directories currently installed.) Preparing to unpack .../base-files_13.8_amd64.deb ...
Unpacking base-files (13.8) over (12.4+deb12u11) ...
Setting up base-files (13.8) ...
Installing new version of config file /etc/debian_version ...
Installing new version of config file /etc/issue ...
Installing new version of config file /etc/issue.net ...
Updating /etc/profile to current default.
Updating /root/.profile to current default.
(Reading database ... 11347 files and directories currently installed.) Preparing to unpack .../libzstd1_1.5.7+dfsg-1_amd64.deb ...
Unpacking libzstd1:amd64 (1.5.7+dfsg-1) over (1.5.4+dfsg2-5) ...
Setting up libzstd1:amd64 (1.5.7+dfsg-1) ...
(Reading database ... 11347 files and directories currently installed.) Preparing to unpack .../0-libgssapi-krb5-2_1.21.3-5_amd64.deb ...
Unpacking libgssapi-krb5-2:amd64 (1.21.3-5) over (1.20.1-2+deb12u3) ... Preparing to unpack .../1-libkrb5-3_1.21.3-5_amd64.deb ...
Unpacking libkrb5-3:amd64 (1.21.3-5) over (1.20.1-2+deb12u3) ...
Preparing to unpack .../2-libk5crypto3_1.21.3-5_amd64.deb ...
Unpacking libk5crypto3:amd64 (1.21.3-5) over (1.20.1-2+deb12u3) ...
Preparing to unpack .../3-libkrb5support0_1.21.3-5_amd64.deb ...
Unpacking libkrb5support0:amd64 (1.21.3-5) over (1.20.1-2+deb12u3) ... Preparing to unpack .../4-libcom-err2_1.47.2-3+b1_amd64.deb ...
Unpacking libcom-err2:amd64 (1.47.2-3+b1) over (1.47.0-2) ...
Preparing to unpack .../5-libkeyutils1_1.6.3-6_amd64.deb ...
Unpacking libkeyutils1:amd64 (1.6.3-6) over (1.6.3-2) ...
Preparing to unpack .../6-kmod_34.2-2_amd64.deb ...
Unpacking kmod (34.2-2) over (30+20221128-1) ...
Preparing to unpack .../7-libkmod2_34.2-2_amd64.deb ...
Unpacking libkmod2:amd64 (34.2-2) over (30+20221128-1) ...
Preparing to unpack .../8-dmsetup_2%3a1.02.205-2_amd64.deb ...
Unpacking dmsetup (2:1.02.205-2) over (2:1.02.185-2) ...
Preparing to unpack .../9-libpcre2-8-0_10.45-1_amd64.deb ...
Unpacking libpcre2-8-0:amd64 (10.45-1) over (10.42-1) ...
Setting up libpcre2-8-0:amd64 (10.45-1) ...
(Reading database ... 11361 files and directories currently installed.) Preparing to unpack .../libdevmapper1.02.1_2%3a1.02.205-2_amd64.deb ... Unpacking libdevmapper1.02.1:amd64 (2:1.02.205-2) over (2:1.02.185-2) ... Preparing to unpack .../libcryptsetup12_2%3a2.7.5-2_amd64.deb ...
Unpacking libcryptsetup12:amd64 (2:2.7.5-2) over (2:2.6.1-4~deb12u2) ... Preparing to unpack .../bacula-director-sqlite3_15.0.3-3_all.deb ... Unpacking bacula-director-sqlite3 (15.0.3-3) over (9.6.7-7) ...
Preparing to unpack .../bacula-common-sqlite3_15.0.3-3_amd64.deb ... Unpacking bacula-common-sqlite3 (15.0.3-3) over (9.6.7-7) ...
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)
Errors were encountered while processing:
/var/cache/apt/archives/bacula-common_15.0.3-3_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

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

Control: severity -1 normal

I don't see the "major impact on the usability" that would classify this
as an important bug, therefore I'm lowering the severity to normal.

If there will be a change to address bug #1109499 for trixie we can
address this one too, otherwise I think we're too far into the freeze to
change it for trixie.

- Carsten

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

Hi,

Chris Hofstaedtler <[email protected]> writes:

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

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.

Regards

Carsten

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

On Wed, Jul 30, 2025 at 09:41:59AM +0200, Carsten Leonhardt wrote:

Hi Adrian,

Hi Carsten,

Adrian Bunk <[email protected]> writes:

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

...

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.

you are saying that when an upgrade that might take over 1 day is
interrupted, it cannot automatically resume or restart.

This is a problem that should ideally be fixed.

...

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".

Do you really want to receive the Release Notes in the form of
100 debconf questions you have to manually acknowledge on every
machine you upgrade?

Users will just be annoyed and click through it without reading,
as is already common on the web.

The user is supposed to read the Release Notes before upgrading,
if the user chooses not to read them that's not our problem.

Regards

Carsten

cu
Adrian

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

Hi,


Adrian Bunk <[email protected]> writes:

On Wed, Jul 30, 2025 at 09:41:59AM +0200, Carsten Leonhardt wrote:

Adrian Bunk <[email protected]> writes:

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

...

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.

you are saying that when an upgrade that might take over 1 day is interrupted, it cannot automatically resume or restart.

This is a problem that should ideally be fixed.

I'm not a database expert, but my guess is that SQL statements do not
result in atomic operations on disk. If the server runs out of space,
loses power or whatever, the database will most probably be in an
undefined state. I wouldn't know how to automatically recover and
continue database operations from the point where it stopped.

So yes, it would be ideal to be able to automatically resume, but I
doubt it's possible. Automatically restarting might be easier, but still
rather complicated and would take even longer than just the database
upgrade because the way I see that it would work would be to restore
from a backup of the database (usually made by dbconfig-common at the
beginning of the upgrade process) and then restart.

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".

Do you really want to receive the Release Notes in the form of
100 debconf questions you have to manually acknowledge on every
machine you upgrade?

Users will just be annoyed and click through it without reading,
as is already common on the web.

The user is supposed to read the Release Notes before upgrading,
if the user chooses not to read them that's not our problem.

As you can guess, I would appreciate getting warned about performing an operation that could possibly result in an outage of services on servers without a direct relation to the server I'm upgrading: There will be
users with a dedicated database server. They can use it for more
applications than just bacula. Even having a redundant database server
setup wouldn't help.

Sure, we can choose to say it's the user's fault for not reading and remembering the release notes.

But my opinion is still to err on the safe side: abort while it's
safe(r) to do so rather than running into an error condition that can be magnitudes harder to resolve, especially while your backup is out of
order.

Regards

Carsten

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

On Fri, Aug 01, 2025 at 07:57:37PM +0200, Carsten Leonhardt wrote:

Hi,

Hi Carsten,

...
I'm not a database expert, but my guess is that SQL statements do not
result in atomic operations on disk.

a core feature of SQL databases is ACID (atomicity, consistency,
isolation, durability).

And this is not limited to single SQL statements:

You can write any number of SQL statements between BEGIN and COMMIT,
and the database ensures that either all of them or none of them happen.

You can put a billion SQL statements in one transaction, and the database ensures that at any point in time either all or none of them are visible.

This includes what is visible to other database users accessing the
database at the same time.

If the server runs out of space,
loses power or whatever, the database will most probably be in an
undefined state. I wouldn't know how to automatically recover and
continue database operations from the point where it stopped.

In all the error scenarios you describe, the well-defined state of an
SQL database is the state without the transaction.

I haven't checked what exactly Bacula does during a schema upgrade,
but what you write sounds as if the problem might not even exist.

...

Do you really want to receive the Release Notes in the form of
100 debconf questions you have to manually acknowledge on every
machine you upgrade?

Users will just be annoyed and click through it without reading,
as is already common on the web.

The user is supposed to read the Release Notes before upgrading,
if the user chooses not to read them that's not our problem.

As you can guess, I would appreciate getting warned about performing an operation that could possibly result in an outage of services on servers without a direct relation to the server I'm upgrading: There will be
users with a dedicated database server. They can use it for more
applications than just bacula. Even having a redundant database server
setup wouldn't help.

Sure, we can choose to say it's the user's fault for not reading and remembering the release notes.

But my opinion is still to err on the safe side: abort while it's
safe(r) to do so rather than running into an error condition that can be magnitudes harder to resolve, especially while your backup is out of
order.

You are not erring on the safe side, you are making debconf unusable.

You want to click through hundreds of debconf confirmation messages on
every machine you are upgrading?

Every maintainer with a package that has a NEWS.Debian might argue the
same way you do, and additionally add a debconf confirmation.

You seem to think that among the ten thousands of packages in Debian
your package is the one that is so super-important that it has to force
its NEWS.Debian through debconf even on users who only want to see
critical debconf quesions.

Depending on how you upgrade and how many machines you upgrade debconf
can be quite annoying, the user either has to manually click through
everything or preseed all answers.

A typical upgrade might upgrade several thousand packages.

debconf questions that are not necessary are a PITA for users,
don't punish everyone for users who did not read the Release Notes.

Regards

Carsten

cu
Adrian

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

Hi,

Adrian Bunk <[email protected]> writes:

On Fri, Aug 01, 2025 at 07:57:37PM +0200, Carsten Leonhardt wrote:

Hi,

Hi Carsten,

...
I'm not a database expert, but my guess is that SQL statements do not
result in atomic operations on disk.

a core feature of SQL databases is ACID (atomicity, consistency,
isolation, durability).

And this is not limited to single SQL statements:

You can write any number of SQL statements between BEGIN and COMMIT,
and the database ensures that either all of them or none of them happen.

You can put a billion SQL statements in one transaction, and the database ensures that at any point in time either all or none of them are visible.

This includes what is visible to other database users accessing the
database at the same time.

This sounds well in theory. In practice I read:

Roll back of incomplete transactions

Incomplete transactions are any transactions that were active at the
time of unexpected exit or fast shutdown. The time it takes to roll
back an incomplete transaction can be three or four times the amount
of time a transaction is active before it is interrupted, depending on
server load.

You cannot cancel transactions that are being rolled back. In extreme
cases, when rolling back transactions is expected to take an
exceptionally long time, it may be faster to start InnoDB with an innodb_force_recovery setting of 3 or greater. See Section 17.20.3, “Forcing InnoDB Recovery”.

Source: https://dev.mysql.com/doc/refman/8.4/en/innodb-recovery.html#innodb-crash-recovery

So if the database operations done during the upgrade of bacula fail
near the end (possibly due to the database server running out of space),
it may take 3-4 days just to roll back in the case of Sven's database
that I referred to earlier.

Another quote from MySQL: "MySQL includes components such as the InnoDB
storage engine that adhere closely to the ACID model [...]" (Source: https://dev.mysql.com/doc/refman/8.4/en/mysql-acid.html)

To me (and others) this reads as "only InnoDB adheres to the ACID
model", the other database engines do not.

(For MariaDB I can only find that they list the ACID principles without
further details on their implementation)

If the server runs out of space,
loses power or whatever, the database will most probably be in an
undefined state. I wouldn't know how to automatically recover and
continue database operations from the point where it stopped.

In all the error scenarios you describe, the well-defined state of an
SQL database is the state without the transaction.

I haven't checked what exactly Bacula does during a schema upgrade,
but what you write sounds as if the problem might not even exist.

For MariaDB/MySQL I've been in the situation myself that I couldn't
cleanly recover from a full disk. It's not always possible to clear up
or add space while the machine is running.

For PostgreSQL: "If you let the disk fill up, you can't recover from within PostgreSQL."
(Source: https://dba.stackexchange.com/questions/167515/dealing-with-disk-space-full-in-postgresql)

Do you really want to receive the Release Notes in the form of
100 debconf questions you have to manually acknowledge on every
machine you upgrade?

Users will just be annoyed and click through it without reading,
as is already common on the web.

The user is supposed to read the Release Notes before upgrading,
if the user chooses not to read them that's not our problem.

As you can guess, I would appreciate getting warned about performing an
operation that could possibly result in an outage of services on servers
without a direct relation to the server I'm upgrading: There will be
users with a dedicated database server. They can use it for more
applications than just bacula. Even having a redundant database server
setup wouldn't help.

Sure, we can choose to say it's the user's fault for not reading and
remembering the release notes.

But my opinion is still to err on the safe side: abort while it's
safe(r) to do so rather than running into an error condition that can be
magnitudes harder to resolve, especially while your backup is out of
order.

You are not erring on the safe side, you are making debconf unusable.

You want to click through hundreds of debconf confirmation messages on
every machine you are upgrading?

Every maintainer with a package that has a NEWS.Debian might argue the
same way you do, and additionally add a debconf confirmation.

You seem to think that among the ten thousands of packages in Debian
your package is the one that is so super-important that it has to force
its NEWS.Debian through debconf even on users who only want to see
critical debconf quesions.

Depending on how you upgrade and how many machines you upgrade debconf
can be quite annoying, the user either has to manually click through everything or preseed all answers.

A typical upgrade might upgrade several thousand packages.

debconf questions that are not necessary are a PITA for users,
don't punish everyone for users who did not read the Release Notes.

I understand you don't like debconf popping up and probably see this
instance as possibly opening a floodgate.

I think I've explained why I think that in this instance it is important
that the users know what they are getting into. It's not about "my
package is exceptionally important" but rather the consequences of
failing to understand that what is about to start can lead to situations
that can take days to recover from. Mind you, the debconf pops up only
when a bacula-director is installed, which is usually only one machine
per site. Popcon reports around 200 installed bacula-director packages,
so the "audience" is rather small.

We obviously have a different opinion on how hard we want to punish
users that don't read and remember the release notes. I'm not aware of a project consensus about how to treat these users.


Lastly, I'll note that a version of bacula with the database upgrade
entered Ubuntu with it's 24.04 release, followed by a version with the
debconf confirmation in the 24.10 release. I don't see bug reports
there, neither about a failed upgrade nor about the debonf confirmation
being unwelcome. My guess is that people with larger installations stick
to LTS releases when running bacula-director on Ubuntu.

Regards

Carsten

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