Upgrade to Yunohost 12 failed with unspecific error

What type of hardware are you using: VPS bought online
What YunoHost version are you running: 11.3.0.2
How are you able to access your server: The webadmin

Describe your issue

On the web UI, I started the migration to Yunohost 12. After some time, the process stopped silently. I searched the logs and found the one below.

What can I do?

Share relevant logs or error messages

https://paste.yunohost.org/raw/eyexonenux

I ran diagnosis from the web UI. Here is the log: https://paste.yunohost.org/raw/pibirogeka

There are two manually modified files mentioned, which I cannot remember to have edited, which does not mean much. Can this be a reason for the failed migration?

Any help will be greatly appreciated. Thanks in advance.

2025-03-06 20:35:45,405: DEBUG - Setting up php7.3-fpm (7.3.33-24+0~20241224.123+debian12~1.gbp64cad4) ...
2025-03-06 20:35:46,644: WARNING - Job for php7.3-fpm.service failed because the control process exited with error code.
2025-03-06 20:35:46,645: WARNING - See "systemctl status php7.3-fpm.service" and "journalctl -xeu php7.3-fpm.service" for details.
2025-03-06 20:35:46,646: WARNING - invoke-rc.d: initscript php7.3-fpm, action "restart" failed.
2025-03-06 20:35:46,664: DEBUG - * php7.3-fpm.service - The PHP 7.3 FastCGI Process Manager
2025-03-06 20:35:46,664: DEBUG -      Loaded: loaded (/lib/systemd/system/php7.3-fpm.service; disabled; preset: enabled)
2025-03-06 20:35:46,664: DEBUG -      Active: activating (auto-restart) (Result: exit-code) since Thu 2025-03-06 20:35:46 CET; 7ms ago
2025-03-06 20:35:46,664: DEBUG -        Docs: man:php-fpm7.3(8)
2025-03-06 20:35:46,664: DEBUG -     Process: 3284894 ExecStart=/usr/sbin/php-fpm7.3 --nodaemonize --fpm-config /etc/php/7.3/fpm/php-fpm.conf (code=exited, status=78)
2025-03-06 20:35:46,664: DEBUG -     Process: 3284896 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/7.3/fpm/pool.d/www.conf 73 (code=exited, status=0/SUCCESS)
2025-03-06 20:35:46,664: DEBUG -    Main PID: 3284894 (code=exited, status=78)
2025-03-06 20:35:46,664: DEBUG -         CPU: 44ms
2025-03-06 20:35:46,664: WARNING - dpkg: error processing package php7.3-fpm (--configure):
2025-03-06 20:35:46,665: WARNING -  installed php7.3-fpm package post-installation script subprocess returned error exit status 1

Please look at the output of journalctl -u php7.3-fpm.service for the service that didn’t restart during setup.

Your diagnosis says that the source for that package has been changed manually. Look at the changes using yunohost tools regen-conf apt --dry-run --with-diff.

In doubt post the outputs here for further diagnosis.

1 Like

Thank you for your response.

I am using web admin gui normally, so I am not used to the console. When trying

sudo journalctl -u  php7-fpm.service

the response is after typing the admin password:

admin is not in the sudoers file.
This incident has been reported to the administrator.

Ironically, the administrator is me, and I have no idea.

The same happens when executing

sudo yunohost tools regen-conf apt --dry-run --with-diff

I guess, I need some help with this.

According to the web admin ui, the admin user is member of the ‘Administratoren’ (english: admins) group, though. But what is the sudoers file, and how can I check it?

Hmfyeah that’s typical of an issue that we have with half-done migration … You need to become root explicitly with su (just su), it’ll ask for the root password which should be the same as your regular user password … or possibly the very first password your chose at postinstall

Then run yunohost tools regen-conf nsswitch and that should fix “sudo”

Anyway, you’re looking for journalctl -u php7.3-fpm.service -n 50 --no-hostname --no-pager (NB: 7.3)

First step forward: su with admin password worked.

Executing yunohost tools regen-conf nsswitch led to this output:

Warning: The configuration file '/etc/nsswitch.conf' has been manually modified and will not be updated
nsswitch:
  applied:
  pending:
    /etc/nsswitch.conf:
      status: modified

Ah yes sorry my bad, forgot the --force option :

yunohost tools regen-conf nsswitch --force

OK, that worked, thank you.

Now doing:

journalctl -u php7.3-fpm.service -n 50 --no-hostname --no-pager

results in many lines of output. I am studying the documentation how to transfer this output here.

Possibly you can pipe it to yunopaste :

journalctl -u php7.3-fpm.service -n 50 --no-hostname --no-pager | yunopaste

it will send it to paste.yunohost.org and return the url

1 Like

Thanks, that is elegant. My attempt was per ftp with some permission issues.

The output is:
https://paste.yunohost.org/raw/axetuqiwoy

Apparently, there is a problem with synapse.

Hmyeah so idk if synapse is still supposed to be installed on your system ? Anyway the most straightforward thing to do would be to remove the corresponding php config bit and deal with it later (such as force-upgrade synapse to regen the conf etc)

so something like : rm /etc/php/7.3/fpm/pool.d/synapse.conf i suppose

Ok, done. Should I now run the migration again?
Btw, Synapse ist still running.

This command, recommended by ChriChri:

yunohost tools regen-conf apt --dry-run --with-diff

results in

The configuration would have been updated for category 'apt'
apt: 
  applied: 
    /etc/apt/sources.list.d/extra_php_version.list: 
      diff: 
      status: managed
  pending: 

Should I run this command with --force?

Now I have successfully run the command

yunohost tools regen-conf apt --force

Here is the diagnosis logfile:
https://paste.yunohost.org/raw/anarevatas

Migration 27 Upgrade the system to Debian Bookworm and YunoHost 12 ist still offered. Is it safe to restart this migration, or is my server in an inconsistent intermediate state?

Yes you can restart the migration :+1:

1 Like

The migration ran to 100%, then an “internal server error” was shown.

Here is the diagnosis output:

https://paste.yunohost.org/raw/ziyavifoja

There are inconsistent version of yunohost-admin and yunohost-portal.

None of the domains are accessible per http.

After running additional migrations, the remaining migration 29 (Postgresql 13 to 15) fails. The Postgresql service is dead.

Here is the logfile when starting postgresql service:

Apparently, PostgreSQL has not been started at all, only the day before (March 6th).

Synapse is not running, Nextcloud seems to.

Now I hope to solve this problem, too.

If I can provide additional debug information, please let me know.