• Bug#1109565: Bug#1109499: bacula-director-sqlite3: fails to dist-upgrad

    From Sven Hartge@21:1/5 to Niels Thykier on Sun Jul 20 12:20:01 2025
    On 20.07.25 09:45, Niels Thykier wrote:

    @Bacula team: I have split this into two bugs for you.

     - #1109499 remains RC and is about preinst defaulting to fail on a
       non-interactive upgrade test.

    The problem here is that this question and the default to "no" is a very important safeguard against a critical upgrade problem WRT the DB
    changes that are going to happen.

    The upgrade path to v15 changes the biggest table in the database in a
    way that it needs huge amount of storage (nearly a TB for my production
    system for example) and if you fail to provide this then the upgrade
    will fail and leave your database in an unusable and very hard to
    recover state, leading to loss of data or the very least non running
    backup and non-functioning restores.

    We are kind-of between a rock and a hard place here, since there is no
    way to programmatically check if the upgrade will succeed with remote
    databases and non-standard database locations involved.

    So IMO the only way to prevent a catastrophic failure is to ask the
    person running the upgrade if it is safe and default to "no" to prevent yes-yes-yes-spamming from ruining the day.

    Grüße,
    Sven.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Sven Hartge@21:1/5 to Paul Gevers on Mon Jul 21 10:20:02 2025
    On 20.07.25 12:44, Paul Gevers wrote:
    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.

    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?

    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.

    I am inclined to just switch the default to true, so automated upgrade
    will work, I have prepared a branch for this.

    Carsten will need to weigh in though.

    I also intent to an addition to the release-notes documenting the need
    for enough space to be available for the upgrade to work.

    Grüße,
    Sven.

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