My migration to YNH 11 - what I encountered (Matrix, Searx, Lufi, and more do not work)

I have over 20 services that I provide for the public. You can see them here https://trom.tf/ - we have a few thousand users.

So. After the migration finishes I see the Migration page and no message. I am left confused to be honest and I think that the process is done. However the diagnosis shows me that the wemadmin failed to upgrade to the latest. I had to SSH into the server and do some “fix broken packages” thingy that was suggested by the webadmin error.

I then saw my Matrix server and other services not working. I thought to reboot the server. After was rebooted they still didn’t work. It seems postgres was running in the background. And I killed it. So I had to go to the Migrations page again and run it from there.

Basically I didn’t get a proper feedback for what was happening. And admins will be confused. Maybe run a diagnosis after the upgrade is done, then if any errors show them in the same Window where the migration happens + instructions of how they can be fixed.

Anyway, I ran the postgres that took some 30 minutes. But then several services were not working.

Matrix synapse won’t start anymore. It seems you have to do a force upgrade to fix it: yunohost app upgrade --force synapse -u https://github.com/YunoHost-Apps/synapse_ynh/tree/master - after that force upgrade it works but am not sure if properly. Still testing.

Lufi:

systemctl status lufi.service
● lufi.service
     Loaded: not-found (Reason: Unit lufi.service not found.)
     Active: failed (Result: exit-code) since Thu 2022-08-18 22:29:28 CEST; 1min 17s ago
        CPU: 224ms

Aug 18 22:29:27 server.trom.tf systemd[1]: Starting Image hosting and sharing service...
Aug 18 22:29:28 server.trom.tf carton[113650]: Encode.c: loadable library and perl binaries are mism>
Aug 18 22:29:28 server.trom.tf systemd[1]: lufi.service: Control process exited, code=exited, status>
Aug 18 22:29:28 server.trom.tf systemd[1]: lufi.service: Failed with result 'exit-code'.
Aug 18 22:29:28 server.trom.tf systemd[1]: Failed to start Image hosting and sharing service.

Searx: https://paste.yunohost.org/raw/osokixihoz

This is ongoing and I am trying to fix stuff…

2 Likes

Matrix disconnects very often… I see this process multiplied in the server processes: postgres: 13/main: matrix_synapse matrix_synapse ::1(34862) SELECT

Here’s a log of what is happening with Matrix now hastebin

I have reinstalled Lufi and Searx. All work now. I have upgraded with force invidious, and works.

Perhaps the last update before I go to bed. All apps seem to work now, granted I had to reinstall a few. Matrix still does not work at all. But I see these in the processes:

I suspect it is still migrating from PostgreSQL 11 to 13 and since the database is 77GB in size, it takes a long long time. I really hope that’s the case.

If anyone thinks it might be something else please let me know.

Damn it was postgres…it took some 7 hours to finish for such a huge database. But now all works fine. Thank you YNH for being awesome. I totally understand that for such big servers like mine, this kind of massive update cannot go that smooth.

4 Likes

Hi all,
Migration completed on 2 instances.
2 minor issues:

-One of my instance is an encrypted Debian on Kimsufi, installed using the following script:

The migration initially failed because grub-pc update required the user to pick the drive/partition on which Grub is to be installed. I launched an apt upgrade manually, set grub, then re-launch the migration script and all went well.

-Invidious (Youtube front-end) was no longer working. Error message:
/var/www/invidious/invidious: error while loading shared libraries: libevent-2.1.so.6: cannot open shared object file: No such file or di
This libevent file version is not available on Debian 11, but the real issue is Invidious must be rebuilt against upgraded dev packages. Fixed by the following if someone needs it:
sudo yunohost app upgrade invidious -u https://github.com/YunoHost-Apps/invidious_ynh --debug --force
There may be more packages that need a rebuild vs upgraded libraries. I’m wondering if that could be “detected” in the future (ex: concerned packages would need a “migration” script forcing a rebuild) ?

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.