My YunoHost server
Hardware: VPS bought online
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 22.214.171.124 (stable)
yunohost version: 126.96.36.199 (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.
- 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.