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

[Carsten Leonhardt]

Hi,


Adrian Bunk <bunk at debian.org> writes:

> On Wed, Jul 30, 2025 at 09:41:59AM +0200, Carsten Leonhardt wrote:
>> Adrian Bunk <bunk at debian.org> 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