[pkg-bacula-devel] Bug#1109499: [debian-mysql] Bug#1109499: bacula-director-sqlite3: fails to dist-upgrade from bookworm to trixie

[Adrian Bunk]

On Thu, Jul 31, 2025 at 03:03:23PM -0700, Otto Kekäläinen wrote:
> > When there are failures, it's not bad when this is immediately visible
> > to the administrator.
> 
> If the server is not fully dedicated to just running Bacula, then
> preventing dpkg/apt from doing anything is a bit overkill just for the
> sake of notifying the user.

It is the only reliable way to notify the user, and appropriate when 
something major failed.

Abort with a good error message, and the user knows that something failed 
and has a good starting point for searching for searching for a solution.

Really bad are silent failures where you only notice some time afterwards 
that something isn't working, and then have to start debugging what the 
problem might be.

In the case of a Backup server, the classical "really bad" would be that 
the user discovered it is not running when he needs to restore from a 
backup that was not created.

> > The postinst will restart the service, which might start the migration
> > in the background.
> >
> > The migration might take a long time.
> >
> > There is likely a recommendation to reboot when the package management
> > system has finished upgrading all packages.
> >
> > The administrator reboots, not being aware that a migration is still
> > running in the background.
> 
> There are many ways to communicate things to the system admin, but if
> they fail, the service would still restart the database schema
> migration etc immediately after restart when the service file would
> try to start Bacula and notice that upgrade wasn't completed.

Rather "would still TRY to restart the migration".

We have to really really really try hard to avoid rebooting while any 
kind of upgrade or migration is ongoing, sice this might create really
nasty breakages.

Can you 100% guarantee that it will never ever cause a problem when
I unplug the power of the machine at any time during mariadb-upgrade?

> > > Doing an upgrade check and upgrading the
> > > database as part of the startup sequence will also behave correctly if the
> > > user is for example restoring an old database from backups and trying to
> > > start it with a new version of Bacula.
> >
> > How do you restore anything from backups when the database of your
> > backup server is broken?
> 
> We are now talking about Bacula's own database schema, right? For
> example, if the hardware was broken and the sysadmin is installing
> Trixie on a new host and installs the latest Bacula but takes the
> Bacula database from the old Bookworm server, the Bacula schema would
> never migrate if it only happens when triggered by dpkg.

Whatever the user does manually is outside the scope of what we 
have to support when upgrading.

> If it is part
> of the service startup, it would always do the upgrade of the database
> scheme when Bacula starts and it detects the stuff on the disk is of
> an older format than what the running binary wants to use.

Far more important is that both before and after the postinst of 
mariadb-server the database server is available.

The scripts of other packages can assume that when a program or service 
is configured to use a database server, then this database server is
available during the upgrade.

Stopping the database server before the upgrade can cause problems.

Still running mariadb-upgrade instead of a running database server after 
the postinst can cause problems.

And if connecting to the configured database fails, this is a serious 
error where aborting from the postinst is appropriate.

There is also a certain irony that you want users to manually stop the 
MariaDB server before the upgrade due to fear of an unclean shutdown
when running the old version, which guarantees that every MariaDB-using
service that gets configured before mariadb-server has an unclean 
shutdown with the old version due to non-availability of the database.

It would cause far less problems if the release notes would instead 
document that in this rare error situation of an unclean MariaDB 
shutdown it is required to downgrade to the bookworm mariadb-server
for error recovery.

cu
Adrian