[debian-mysql] Bug#1109499: bacula-director-sqlite3: fails to dist-upgrade from bookworm to trixie
Adrian Bunk
bunk at debian.org
Thu Jul 31 19:35:38 BST 2025
On Thu, Jul 31, 2025 at 10:35:18AM -0700, Otto Kekäläinen wrote:
> Hi!
Hi Otto!
> I skimmed through https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1109499
> quickly and my initial thought here is that Bacula (or any other program)
> should not rely on dpkg maintainer scripts to upgrade the database as there
> isn't any guarantees about what the initial state is, and if anything fails
> it's really hard to restart or recover. Any failures happening during a
> dpkg run in general will block the upgrades/installs/uninstalls for the
> whole system as apt will refuse to do any new actions until the pending
> dpkg package action has completed successfully.
When there are failures, it's not bad when this is immediately visible
to the administrator.
> Instead I would recommend to do the upgrade as part of the systemd/init
> service startup sequence. If it fails it's much easier to restart and debug
> and the failure will only affect one single service, not the whole OS
> package management system.
That sounds like a bad idea to me.
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.
> 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?
cu
Adrian
More information about the pkg-mysql-maint
mailing list