Nextcloud - Internal server error après upgrade YNH 11

Mon serveur YunoHost

Matériel: vieux PC
Version de YunoHost: 11.0.9
J’ai accès à mon serveur : En SSH | Par la webadmin | En direct avec un clavier/écran |
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : oui
Si oui, expliquer:
Upgrade YNH 4 => YNH11

Description du problème

Bonjour, et merci pour tout ce que vous faites :slight_smile:
J’ouvre ce topic parce que j’ai fait la migration vers Bullseye et depuis, je rencontre ce message en essayant de me connecter à mon instance NC.

Internal Server Error

The server encountered an internal error and was unable to complete your request.
Please contact the server administrator if this error reappears multiple times, please include the technical details below in your report.
More details can be found in the server log.

J’ai essayé de mettre à jour les paquets, relancer le service nginx, réinstaller php7.4 mais rien n’y fait. Dans le fichier nextcloud.log le dernier log date de Juillet (j’ai fait la montée de version il y a quelques jours). Le seul log intéressant que j’ai trouvé est le servername.log :

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

Ce log semble indiquer un incident au niveau de php7.4 mais je n’ai aucune idée de quoi faire ensuite. Sauriez-vous m’aider ?

Pour information, voici le résultat de dpkg --list | grep php :

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

En vous remerciant par avance

Pour une raison obscure (peut-être que la migration 0021 buster->bullseye n’est pas allée jusqu’au bout …) il manque le paquet php7.4-apcu, donc:

apt install php7.4-apcu

Bonjour Aleks, merci pour ta réponse !
Oui j’ai eu quelques soucis lors de la migration.
J’ai réinstallé le paquet puis relancé le service nginx, obtenu le message suivant :

    Le module PHP zip n’est pas installé.
    Veuillez demander à votre administrateur d’installer le module.
    Les modules PHP ont été installés mais sont toujours indiqués comme manquants ?

    Veuillez demander à votre administrateur serveur de redémarrer le serveur web.

J’ai donc installé le paquet php-zip et Nextcloud est de nouveau fonctionnel !
Merci beaucoup et bonne soirée :slight_smile:

Heuuuarrg j’espère que c’était php7.4-zip et pas php-zip … la différence est très technique et complexe à expliquer mais importante …

J’ai le même genre d’erreur (globale, sans plus de log) et ces paquets sont déjà installés… hastebin

Est-ce que ça peut-être en lien ?
Dans mon cas c’est un problème avec la base de donnée mysql apparemment. Plus de détails: YunoHost 11.0 (Bullseye) release / Sortie de YunoHost 11.0 (Bullseye) - #171 by Lapineige

Tu confirmes que l’erreur concerne nextcloud / php7.4 ?

Sur le coup je me suis dit ouuuups :laughing: et puis finalement il semblerait que apt ait ajouté le php7.4 :

Les paquets supplémentaires suivants seront installés :
  php7.4-zip
Les NOUVEAUX paquets suivants seront installés :
  php-zip php7.4-zip
0 mis à jour, 2 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 27,8 ko dans les archives.
Après cette opération, 112 ko d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer ? [O/n] o
Réception de :1 http://ftp.debian.org/debian bullseye/main amd64 php-zip all 2:7.4+76 [6 360 B]
Réception de :2 https://packages.sury.org/php bullseye/main amd64 php7.4-zip amd64 1:7.4.30-3+0~20220627.69+debian11~1.gbpf2b381 [21,4 kB]
27,8 ko réceptionnés en 0s (160 ko/s)
Sélection du paquet php7.4-zip précédemment désélectionné.

Donc tout va bien je suppose

Mouai je ferais quand même un apt remove php-zip et apt install php7.4-zip

J’ai un peu cherché sur Internet (emvie d’apprendre un peu) mais je n’ai rien trouvé sur la différence entre php7.4-zip et php-zip (sauf le fait que le second est un paquet virtuel qui pointe vers la dernière vension et est lonc variable dans le temps).

Du coup, je sais que ce n’est pas le sujet mais si c’est un changement (et pas juste cette histoire de paquet virtuel), est ce que c’est possible d’avoir une piste sur quou chercher ?

Hmf so basically part of the full story is that some php-foo packages were virtual dependency that could be satisfied by many other virtual packages (cf PHP dependency madness: episode 7514482, fixing through automatic PR on apps... · Issue #1627 · YunoHost/issues · GitHub )

One other concern is that there’s no guarantee that php-foo will always point to the 7.4 version. Because Sury may decide to stop mapping them to 7.4 and to map them to 8.0 instead (or this will happen when upgrading from Bullseye to Bookworm, the next Debian)

And then apt shitstorms ensues

We had a lot of these in the past, hence my paranoia and pedantry about this.

1 Like

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