Migration to YNH11 runs great, but not every time: MariaDB issue

[wbk]

My YunoHost server

Hardware: VPS bought online
YunoHost version:
Server hardware architecture is kvm amd64
Server is running Linux kernel 4.19.0-21-amd64
Server is running Debian 10.13
Server is running YunoHost 4.4.2.14 (stable)
yunohost version: 4.4.2.14 (stable)
yunohost-admin version: 4.4.1 (stable)
moulinette version: 4.4.1 (stable)
ssowat version: 4.4.1 (stable)

I have access to my server : Through SSH | through the webadmin | VNC terminal
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : yes, Borg backup complains that the target for saving the backup is mounted via SSHFS.

Description of my issue

The migration has been running flawless for a couple of servers, thank you all involved!

For some servers I also run into a MySQL/MariaDB related problem,

2022-09-19 22:57:12,113: INFO - + Processing triggers for mariadb-server-10.3 (1:10.3.36-0+deb10u1) ...
2022-09-19 22:57:12,181: WARNING - postinst called with unknown argument 'triggered'
2022-09-19 22:57:12,200: WARNING - dpkg: error processing package mariadb-server-10.3 (--configure):
2022-09-19 22:57:12,200: WARNING -  installed mariadb-server-10.3 package post-installation script subprocess returned error exit status 1
2022-09-19 22:57:12,205: WARNING - Errors were encountered while processing:
2022-09-19 22:57:12,205: WARNING -  mariadb-server-10.3
2022-09-19 22:57:12,304: WARNING - E: Sub-process /usr/bin/dpkg returned an error code (1)
2022-09-19 22:57:13,305: ERROR - Migration 0021_migrate_to_bullseye did not complete, aborting. Error: Failed to reinstall mariadb-common ?
Traceback (most recent call last):
  File "/usr/lib/moulinette/yunohost/tools.py", line 944, in tools_migrations_run
    migration.run()
  File "/usr/lib/moulinette/yunohost/data_migrations/0021_migrate_to_bullseye.py", line 174, in run
    raise YunohostError("Failed to reinstall mariadb-common ?", raw_msg=True)
yunohost.utils.error.YunohostError: Failed to reinstall mariadb-common ?

First time I encountered it, I tried restarting the migration (you never know, after all). When that didn’t work, I tried upgrading MariaDB manually, before starting the migration. After trying a bit, and rebooting the machine (I noticed it had been running close to a year), the migration ran flawless.

The second time I encountered it (actually the log above is from the second time), I didn’t do any troubleshoot before rebooting (it also didn’t boot for a year) and retrying (after having apt fixing-broken). No luck though; lstu might have been held (I unheld it before checking), no other packages are held.

This time manually upgrading mariadb ran into an error, first missing equivs, then dh-autoconf. Once I installed dh-autoconf, mariadb-server-10.3 got set up.

The migration still did not get through tough, and it seems that mariadb 10.3 did not get fully configured either: when retrying the migration, it gets stuck there again, and manual installation (apt install mariadb-server ) tries to upgrade to 10.3 again, failing upon complaining about dh-autoconfig needing to be >=17, while version 20 is installed.

TL;DR:

• Migration runs into an error because unknown argument 'triggered' for Mariadb
• Manual upgrade (apt install mariadb-server) tries to upgrade to 10.3 (not 10.5), and incorrectly complains about missing dependencies, mainly dh-autoconfig <=17~
• Maybe related: the server didn’t reboot in a while before attempting the migration.

Any idea?

[Lapineige]

@wbk

This time manually upgrading mariadb ran into an error, first missing equivs, then dh-autoconf. Once I installed dh-autoconf, mariadb-server-10.3 got set up.

I remember something like this when I migrated… Could it be related to my issue ? Issues with Mysql/InnoDB after Bullseye migration

Is your mariadb server running ?

Do you have Nextcloud installed ? And working ?

[wbk]

@Lapineige

Could it be related to my issue ? Issues with Mysql/InnoDB after Bullseye migration

I read your post, I skimmed that problem on another server, where the migration (and the server) seemed to hang for ages. In that case, I could (barely) log in via SSH (took minutes to get a shell), and reboot the machine. When restarting the migration, it was done in seconds. No problems after that.

@Lapineige

Is your mariadb server running ?

Do you have Nextcloud installed ? And working ?

In this case: yes, Nextcloud is installed, and working. The (attempted) upgrade is the first step after changing the apt-sources, and does not seem to really break anything.

Oh wait, that was another server :-/

This one only has a redirect to that Nextcloud

Would you think I can run apt upgrade, without guidance of the migration script? The script seems to skip superfluous depends and do some more tuning, so in this case I’m hesitant to just run the whole upgrade outside of the Yunohost-framework.

I started picking random bits of the ~700 upgradable packages, and got down to ~450, when an intermediate apt update hang on contacting sury.org. I think it has been ages since that line is removed from most Yunohosts, so I removed it and gave the migration another try. No luck.

Many packages can’t be updated, because

The following packages have unmet dependencies:
 libglib2.0-0 : Breaks: libgirepository-1.0-1 (< 1.62.0-4~) but 1.58.3-2 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

Trying to reinstall either of those, apt suggests to remove Yunohost and Yunohost-admin. While I’m touched by the ‘Yes, do as I say!’-option, I am not quite sure that is the way to go.

Any suggestion?

[wbk]

OK, things got from bad to worse while experimenting.

I whispered ‘Do as I say’, which let me upgrade Python3 and lose Yunohost.

After reinstalling Yunohost and Yunohost-admin, Yunohost asks me to (savagely) re-run post-install.

I forgot where the post-install-check file is located, I’ll first complete the dist-upgrade and see if anything can be saved from there.

For the savage post-install I’ll open another thread, as suggested by that message. I’ll post the outcome back here

(OK, one more big Oh Noh: after running _all of the dist-upgrade, apt thinks it is necessary to revert to MariaDB 10.3 Only after also removing roundcube-ynh-deps wordpress-ynh-deps, apt was apt to upgrade to 10.5)

[tituspijean]

FYI it looks like the original issue is known by the MariaDB team: [MDEV-29584] Fix upstream Buster MariaDB packaging problem postinst called with unknown argument 'triggered' - Jira

[wbk]

@tituspijean

FYI it looks like the original issue is known by the MariaDB team: [MDEV-29584] Fix upstream Buster MariaDB packaging problem postinst called with unknown argument ‘triggered’ - Jira

Thanks, sharp find!

It could be a newly introduced problem, the mailing-list item that caused the bug entry is from the same day as my post; I didn’t find a related issue while performing the upgrade earlier.

Too bad… The Yunohost running that MariaDB is as non-functional now as it can get by my ‘repairs’.

[Lapineige]

Good catch !

So this links to this patch : https://salsa.debian.org/illuusio/mariadb-10.3/-/commit/6287718533d0dc22ae13e394935ee63e2b7d3a24
Merged upstream on 28th September 2022.

So in theory it should eventually be available for Debian Buster, and then we will be able to upgrade to that patched version and it will fix this issue.

But meanwhile… how do we fix this ? How to manually apply that patch ? Can we edit apt cache files to change the file ?

edit: rerunning the migration should “fix” this.