Migration bullseye non parachevé php7 & guile-2.2-libs

Mon serveur YunoHost

Matériel: VPS
Version de YunoHost: Propulsé par YunoHost 4.4.2.14 (stable) mais :

 lsb_release -a                                                                                        
No LSB modules are available.                                                                                          
Distributor ID: Debian                                                                                                  
Description:    Debian GNU/Linux 11 (bullseye)                                                                          
Release:        11                                                                                                      
Codename:       bullseye 

J’ai accès à mon serveur : En SSH | Par la webadmin | …
Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Si oui, expliquer:

Description du problème

Après avoir tenté une première fois la migration et être tombé sur un premier message d’erreur relatif à maria-db, j’ai relancé la migration comme expliqué dans un autre post pour la solution au premier problème.

Cette deuxième fois, la migration démarre, prends pas mal de temps, et je tombe sur l’erreur suivante :

2022-10-03 18:28:22,413: WARNING - Errors were encountered while processing:
2022-10-03 18:28:22,414: WARNING -  php7.0-fpm
2022-10-03 18:28:22,414: WARNING -  php7.0
2022-10-03 18:28:22,817: WARNING - E: Sub-process /usr/bin/dpkg returned an error code (1)
2022-10-03 18:28:26,141: WARNING - Impossible de mettre à jour les paquets suivants : guile-2.2-libs

voir les logs complet ici

J’ai maintenant manifestement Debian 11 (lsb release -a revoit bullseye), mais je vois toujours la migration à faire dans l’interface web.

relancer la migration donne toujours une erreur log

Que doit-je tenter ?

  1. Mettre à jour tous les paquets, passer la migration et faire celle qui arrivent juste après ?
  2. quelque chose d’autre dans un autre ordre ?

ah et du coup Il y a ce diagnostique qui est apparu en même temps :

Le fichier de configuration /usr/share/yunohost/yunohost-config/ssl/yunoCA/openssl.cnf semble avoir été modifié manuellement.

    C'est probablement OK si vous savez ce que vous faites ! YunoHost cessera de mettre à jour ce fichier automatiquement ... Mais attention, les mises à jour de YunoHost pourraient contenir d'importantes modifications recommandées. Si vous le souhaitez, vous pouvez inspecter les différences avec yunohost tools regen-conf ssl --dry-run --with-diff et forcer la réinitialisation à la configuration recommandée avec yunohost tools regen-conf ssl --force

Petit up de ce topic, car j’ai le certificat Let’s encrypt qui refuse maintenant de ce mettre à jour, et je voudrais pas tout casser.

J’ai fini par faire

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