Super, par contre j’ai encore quelque chose d’anormal, 2 clusters pg, je pense que le premier avec postgresql 11 ne devrait pas fonctionner…
~$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
11 main 5432 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
13 main 5433 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log
Salut,
Migration de mon serveur YunoHost virtualisé avec Pimox(Proxmox pour Raspberry pi4) réalisée sans problème à condition de le faire en console avec “yunohost tools migrations run --accept-disclaimer” avec l’interface graphique ça ne marche pas, pour réparer dans ce cas un petit coup de “dpkg --configure -a” en console et reprendre la migration en console avec “yunohost tools migrations run --accept-disclaimer”.
(j’avais cloné mon yunohost avant pour faire des tests, pratique la version Pimox de Proxmox)
Merci et bravo pour le travail
Migration sans aucun problème en Yunohost 11.0.9.9 (stable) sur un VPS Hetzner.
Le seul service qui ne tournait plus après était Pleroma (Erreur 502).
Il a suffit de l’arrêter totalement, puis de le relancer.
Le reste des applications (Gitea, HedgeDoc, WordPress, Privatebin, Rainloop) ont fonctionnées directement après la mise à jour de Debian et Yunohost.
Solution for glitch-soc and/or plemora was to switch the port of the running postgress cluster from 5433 to 5432 in /etc/postgresql/13/main/postgresql.conf.
Restart the psql service and the installation works again!
I’m still stuck with postgresql migration (see above, problem with mobilizon).
Did anyone solve that issue?
Since mobilizon obviously is causing the problem, I deinstalled it. Sadly I still can not migrate postgresql.
Since there are other applications that are affected by that problem (mastodon, matrix, moodle, pixelfed, peertube, …) I’m now at the point that I want to delete (“DROP”) the mobilizon database by hand:
@chmeyer : I think some people managed to work around the issue by uninstalling Mobilizon then restoring a backup, which should effectively behind the scene restore the SQL DB on postgresql 13 instead of 11, somewhat making the migration that way
(Also I confirmed with some people familiar with postgis (a postgres extension for geographical data) that it’s a mess to upgrade postgresql version when that module is involved, though I don’t have any exact detail to back this up)
I have a similar problem with Mobilizon. I have done like this. I kept a backup of mobilizon (done before). I remove the app (don’t forget remove also the folder /home/yunohost.app/mobilizon)
I delete all postgresql, also the folder /etc/postgresql/11.
Be sure no other postgresql cluster are running: ps -C postgres this command will show if one is running.
then remove purge all postgresql, also folders
Then I restore my mobilizon app, and it works…
For info:
$ dpkg --list | grep postgis
ii postgis 3.2.2+dfsg-1.pgdg110+1 amd64 Geographic objects support for PostgreSQL
ii postgis-doc 3.2.2+dfsg-1.pgdg110+1 all Geographic objects support for PostgreSQL -- documentation
ii postgresql-13-postgis-3 3.1.1+dfsg-1 amd64 Geographic objects support for PostgreSQL 13
ii postgresql-13-postgis-3-scripts 3.1.1+dfsg-1 all Geographic objects support for PostgreSQL 13 -- SQL scripts
$ pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
13 main 5432 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log
My instance Mobilizon: mobilizon.linux07.fr
The only strange thing is that I have to reinitialize my password, I don’t know really why ?
okay, I wanted to be cautious, so I first tried simply DROPing the DATABASE mobilizon. It worked like a charm and # LC_ALL=C pg_upgradecluster -m upgrade 11 main went with
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with
pg_dropcluster 11 main
Ver Cluster Port Status Owner Data directory Log file
11 main 5433 down postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
Ver Cluster Port Status Owner Data directory Log file
13 main 5432 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log
But after that there still was an outstanding migration in the WebGUI. So I started migration again, again with “success” in the GUI.
Now I see this:
# systemctl status postgresql.service
● postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Fri 2022-08-26 20:48:16 CEST; 1min 5s ago
Process: 2971915 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 2971915 (code=exited, status=0/SUCCESS)
CPU: 2ms
Aug 26 20:48:16 yunohost systemd[1]: Starting PostgreSQL RDBMS...
Aug 26 20:48:16 yunohost systemd[1]: Finished PostgreSQL RDBMS.
# pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
13 main 5433 down postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log
# dpkg --list | grep postgis
ii postgis 3.1.1+dfsg-1 amd64 Geographic objects support for PostgreSQL
ii postgis-doc 3.1.1+dfsg-1 all Geographic objects support for PostgreSQL -- documentation
ii postgresql-11-postgis-2.5 2.5.1+dfsg-1 amd64 Geographic objects support for PostgreSQL 11
ii postgresql-11-postgis-2.5-scripts 2.5.1+dfsg-1 all Geographic objects support for PostgreSQL 11 -- SQL scripts
ii postgresql-13-postgis-3 3.1.1+dfsg-1 amd64 Geographic objects support for PostgreSQL 13
ii postgresql-13-postgis-3-scripts 3.1.1+dfsg-1 all Geographic objects support for PostgreSQL 13 -- SQL scripts
# less /var/log/postgresql/postgresql-13-main.log
#
(is an empty file)
In the GUI I see that service postgresql is inactive since more than 52 years, but it says it is activated on boot.
So I see that Port 5433 (should be 5432) has status down and I wonder if I killed postgresql 13 by executing the migration a second time.
Can please anyone give a hint how to fix that?
Is it save to purge the dpkg postgresql-11 packages ?
I told you I have similar problem, the solution for me was remove mobilizon but keep a backup, remove purge all postgresql,
then restore the backup of the app mobilizon, the restoration will create postgresql and upload the good packages… I think it was the solution… Also mobilizon was the only app which use postgresql for me… Now mobilizon works and there is only postgresql 13 working, I think the restoration have found the postgresql-13-postgis-3 and postgresql-13-postgis-3-scripts automatically.
Thank you @rodinux ,
finally I’m now running YNH 11 with pq 13, too.
But since I used other apps that needs postgresql, it didn’t go that easy.
I did, what you told me, but that crashed my Invidious, Mastodon, Moodle, Peertube, Pixelfed, Pleroma and Synapse.
So after some fiddeling I ended with uninstalling all of them, purging postgresql* and then restoring the apps from backup. Well, it took me some hours but now everything is running fine again.