Yunohost v11 migration php7.0-fpm issues

[andy_0]

Hey all,

I encountered an issue migrating to v11 and wanted to report so it may help others if they encounter the same. Trying to migrate to v11 worked fine for quiet some time however somewhere around the end it broke.

Infos about my server

I am using an “old installation” started with around Yunohost 2 and migrated until v11 without re-installation. I am using several Apps such as seafile, sogo and vaultwarden. During the years I was using roundcube and rainloop but deinstalled those months ago.

Migration

Error

Trying to migrate generated the following error:

Warning: Errors were encountered while processing:
Warning:  php7.0-fpm
Warning:  php7.0
Warning: E: Sub-process /usr/bin/dpkg returned an error code (1)
Warning: Could not upgrade packages: guile-2.2-libs, libobjc4
Info: The operation 'Upgrade system packages' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220811-152303-tools_upgrade' to get help
Warning: unable to retrieve string to translate with key 'Could not upgrade all the packages' for default locale 'locales/en.json' file (don't panic this is just a warning)
Error: Migration 0021_migrate_to_bullseye did not complete, aborting. Error: Could not upgrade all the packages
Info: The operation 'Run migrations' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220811-152237-tools_migrations_migrate_forward' to get help

Solution

It turned out that an php7.0-fpm error is the missing /var/www/rainloop folder on my hard drive. This can be seen when trying to deinstall php7.0-fpm using apt. Adding the directory got me one step further but didn’t solve the migration error.

Diging deeper and trying to understand why the system is actually looking for/into /var/www/rainloop I discovered the configuration folder in /etc/php/7.0/fpm/pool.d containing configurations - among others - for rainloop.conf and roundcube.conf.

Server state

After migration I got the notification that php7.0-fpm service is not running however I was able to start it manually (see “Yunohost Webadmin Diagnosis”). My Seafile installation is broken (seafile service is running, seahub service can’t start) but everything else is working as far as I can tell.

tldr

Failing to migrate because of php7.0-fpm might be caused due to outdated configuration files of deleted apps in /etc/php/7.0/fpm/pool.d. Removing the outdated configuration might solve your issue.

[Aleks]

(Uuuuuugh php7.0-fpm is not supposed to be here anymore x_x php7.0 was from the stretch era)

[mib]

Bonjour la communauté,

J’ai installé yunohost le 19/10/2015 si je me fie au premier mail que je me suis envoyé depuis mon instance.

Depuis cette date mon instance a migré d’un pc 64 Bit vers une vm proxmox via un script rsync.

Mercredi lors de la migration j’ai eu le même problème que @andy_0
Du coup j’ai restauré ma vm avec le snapshot que j’avais fais juste avant, puis je l’ai cloné pour solutionner mon problème avec cette machine de test.

En effet dans /etc/php/7.0/fpm/pool.d j’avais des fichiers de configurations d’applications existantes comme supprimées, j’ai supprimé ces fichiers puis désinstallé php7.0-fpm.

En lisant le retour de ma console de migration j’ai constaté que certaines dépendances d’applications supprimées comme dokuwiki-ynh-deps et freshrss-ynh-deps étaient présentes, je les ai supprimé.

Puis je relance la migration, qui arrive à son terme cette fois et je redémarre le système.

Après le reboot je vérifie mes applications et je constate que nextcloud a une erreur de Memcache \OC\Memcache\APCu not available for local cache
Je corrige le problème avec un echo apc.enable_cli=1 >> /etc/php/7.4/cli/php.ini

Et je réinstalle ffsync depuis la branche, l’application fonctionne

GitHub - YunoHost-Apps/ffsync_ynh at bullseye

J’ai appliqué cette procédure sur ma vm de production avec succès.

Grand merci à tous pour cette superbe distribution.

[Lapineige]

I do have a server where it is still there, as a remaining piece of Wordpress… but not used as far as I know.

[andy_0]

Thanks mib for your comment. So it seems this is an issue related to systems originally installed several years ago.

What do you recommend Aleks? Should we deinstall old-ish php packages? I have several of them installed. The migration manager could check for those and either handle it automatically or state that “migration can only continue if php7.x has been deinstalled”.