Problèmes pendant la migration

Matériel: PC fixe
Version de YunoHost: 3.8.5.5
J’ai accès à mon serveur : console locale uniquement
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non

Bonjour,

J’ai tenté une migration vers YNH 4.x, mais un message d’erreur me dit que yunohost-api s’est arrêté en cours de route, interrompant la migration. Je redémarre le service, et me reconnecte, retourne dans la section mises à jour. Un message me dit “Il y a des migrations en suspens qui attentent d’être exécutées. Veuillez aller dans Outils > Migrations pour les exécuter.”, ce que je fais, mais ça me redirige sur la page d’accueil de l’interface admin.

Je tente donc d’installer les paquets qui étaient alors en attente, mais là, ça bloque depuis 10 bonnes minutes à l’étape “[…] Restarting virtual private network daemon.:”, et j’ai l’intuition que ça n’est pas normal que ça dure si longtemps. Dois-je encore attentre ou est-ce que je peux interrompre le processus ?

Si la webadmin s’est déconnectée en cours de migration, celle-ci continue à progresser même si tu ne le vois plus. J’attendrais encore bien alors, et vérifie par exemple 3h après le début de la migration pour voir si celle-ci n’a pas abouti !
Enfin si je comprends bien ce que tu racontes :slight_smile:

J’ai lancé la migration via la ligne de commande, mais ça n’a rien changé, je suis toujours à l’ancienne version. J’ai toujours les paquets suivants à mettre à jour:

moulinette (de 3.8.1.3 à 4.0.3)
ssowat (de 3.8.0.3 à 4.0.3+202007291517)
yunohost-admin (de 3.8.3.5 à 4.0.3)
yunohost (de 3.8.5.5 à 4.0.3)

Mais à chaque essai, quel que soit le temps que j’attends, pas le moindre changement.

Bon, maintenant, c’est encore pire. J’ai voulu jouer à l’apprenti sorcier et j’ai tenté un dist-upgrade. Comme yunohost-api avait planté et que je n’avais pas réussi à le redémarrer, j’ai redémarré tout le serveur. Bien mal m’en a pris, parce que maintenant, plus moyen de démarrer le service nginx ni me connecter en ssh.

Le message d’erreur

nginx: [emerg] BIO_new_file("usr/share/yunohost/other/ffdhe2048.pem") failed (SSL: error:02001002:system library:fopen:No such file or directory:fopen('usr/share/yunohost/other/ffdh2048.pem','r') err

Au delà, le message est tronqué, obligé de le copier à la main à partir de la console locale vu que je ne peux plus me connecter en ssh.

J’ai un ami qui a fait la migration (il avait quelques apps d’installés), et tout semble s’être déroulé correctement.

Par contre, me concernant, j’ai un peu peur : j’utilise VPNadmin, et si l’installeur plante, bonjour les dégâts ! Puis, j’ai une instance PeerTube ! Y-a-t-il possibilités d’avoir des retours pour ceux qui sont quasiment dans la même situation que moi ?

Tu es sur que le chemin du fichier (usr/share/...) n’a pas de / au début ?

Sinon, est-ce que tu peux confirmer que le fichier existe ou non en faisant

ls /usr/share/yunohost/other/ffdhe2048.pem

Oui, j’ai recopié le message d’erreur tel quel.
EDIT: Après vérification, il y avait bien le “/” au début.
Et non, le fichier n’existe pas.

Mokay bon j’allais proposer un apt install yunohost --reinstall mais vu que tu es au milieu de la migration c’est pas pertinent et ça va se résoudre normalement tout seul une fois qu’on aura fait la migration

Du coup pour investiguer pourquoi l’upgrade ne se fait pas vers yunohost 4.0, j’imagine que c’est aussi la même blague avec sury que sur le thread de la release. Donc regardons / confirmons ça avec :

apt install yunohost openssl

Je viens de lancer la commande et il a installé quelques paquets. Après ça, la situation a semblé se débloquer.

Sauf que maintenant, la console me dit que je dois entrer le domaine principal et le mot de passe admin, et me demande si je veux bien procéder à la post installation, comme si mon serveur avait été remis à zéro, et ça ne me rassure pas.

Donc je fais quoi ? Je valide ?

J’ai tapé ‘n’, et tout est rentré dans l’ordre comme si de rien n’était. Mon serveur est à nouveau accessible et tous mes services fonctionnent

Enfin presque. Parce que l’interface web me demande aussi de définir le nom de domaine (alors qu’il le connaît déjà), le mot de passe et de faire la post-install. Du coup, je fais quoi ?

Beh ça aurait pu être cool d’avoir les logs de ce que apt racontait après avoir fait apt install yunohost openssl … mais du coup tu peux tenter un touch /etc/yunohost/installed pour résoudre le soucis de “il veut refaire la postinstall” (même si c’est pas clair pourquoi ça se produit…)

La commande n’a retourné aucun résultat.

Oui elle n’est pas censée en retourner … Du coup retente d’aller sur la webadmin …

Par contre apt en a bien retourné un et je réitère si tu as encore les logs ce serait cool pour essayer de comprendre de notre côté et corriger le soucis pour tout le monde …

C’est bon, la webmin est de nouveau accessible et je suis bien à la version 4.0.3.

Juste un détail: il restait 3 étapes pour une migration totale, mais une a échoué.
https://paste.yunohost.org/raw/ahuwuyizuv

EDIT: c’était trop beau, peertube et lstu me retournent une erreur 502 alors que les services qui les concernent tournent.

En fait, j’ai de gros blocages avec postgresql. Je ne peux rien faire qui y soit lié, et il ne figure même pas dans la liste des services. j’ai tenté un “apt install postgresql”. L’installation a marché, mais aucun changement.

Quid de systemctl status postgresql@11-main ?

Si il dit que le service n’existe pas, tente un apt install postgresql-11

root@stemy:~# systemctl status postgresql@11-main
● postgresql@11-main.service - PostgreSQL Cluster 11-main
   Loaded: loaded (/lib/systemd/system/postgresql@.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Jul 30 17:29:28 stemy.me systemd[1]: Starting PostgreSQL Cluster 11-main...
Jul 30 17:29:31 stemy.me systemd[1]: Started PostgreSQL Cluster 11-main.
Jul 30 17:48:10 stemy.me systemd[1]: Stopping PostgreSQL Cluster 11-main...
Jul 30 17:48:11 stemy.me systemd[1]: postgresql@11-main.service: Succeeded.
Jul 30 17:48:11 stemy.me systemd[1]: Stopped PostgreSQL Cluster 11-main.

Quand je tente un restart, il me retourne ceci:

Assertion failed on job for postgresql@11-main.service.

J’ai réinstallé postgresql et maintenant, le service tourne.

Mais à part ça, zéro changement, les apps concernées ont toujours les mêmes pannes.

Y’a du nouveau: j’ai carrément réinstallé tout le serveur, non sans mal. Et tout ça pour rien car les problèmes de postgresql sont toujours là.

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

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

Apparement il n’a pas pu créer le cluster par défaut à cause d’une erreur stupide de locale … (Coucou @ljf , t’avais raison après tout lole …)

2020-08-05 15:56:13,195: DEBUG - Setting up postgresql-11 (11.7-0+deb10u1) ...
2020-08-05 15:56:13,697: WARNING - Error: The locale requested by the environment is invalid:
2020-08-05 15:56:13,697: WARNING -   LANG: fr_BE.UTF-8
2020-08-05 15:56:13,698: WARNING -   LANGUAGE: fr_BE:fr
2020-08-05 15:56:13,698: WARNING -   LC_ALL: en_US.UTF-8
2020-08-05 15:56:13,698: WARNING - Error: could not create default cluster. Please create it manually with
2020-08-05 15:56:13,699: WARNING - 
2020-08-05 15:56:13,699: WARNING -   pg_createcluster 11 main --start

Du coup je tenterais un pg_createcluster 11 main --start

1 Like