Mise à jour à Debian 11.4

Du coup le patch un peu bourrin fait automatiquement pendant la migration consiste à faire :

sudo sed -i /var/lib/dpkg/status -e 's@Conflicts: apache2, bind9, dovecot-core (>= 1:2.3.7), fail2ban (>= 0.11), iptables (>= 1.8.3), iptables-persistent, nginx-extras (>= 1.16), openssl (>= 1.1.1o), redis-server (>= 5:5.1), slapd (>= 2.4.49)@Conflicts: apache2, bind9@g'

(en gros ça supprime le conflit entre Yunohost et d’autres paquets, qui était une “astuce” pour empêcher des catastrophes liés aux backports et autres trucs …)

Ensuite le apt full-upgrade devrait marcher mieu

# sudo sed -i /var/lib/dpkg/status -e 's@Conflicts: apache2, bind9, dovecot-core (>= 1:2.3.7), fail2ban (>= 0.11), iptables (>= 1.8.3), iptables-persistent, nginx-extras (>= 1.16), openssl (>= 1.1.1o), redis-server (>= 5:5.1), slapd (>= 2.4.49)@Conflicts: apache2, bind9@g'

# dpkg-query -s yunohost | grep '^Conflicts:'
Conflicts: apache2, bind9

Ça modifie bien la ligne concernant les conflits concernant le paquet yunohost.

J’ai lancé un apt update suivi d’un apt full-upgrade et l’upgrade semble fonctionner.

J’attends de voir si tout retombe en marche pour confirmer ta solution mais ça semble avoir débloqué la situation. Merci :slight_smile:

Pendant l’apt full-upgrade, j’ai eu plusieurs warnings. Notamment :

Warning: Migration 0021_migrate_to_bullseye has to be run manually. Please go to Tools → Migrations on the webadmin page, or run `yunohost tools migrations run`.
Error: Run these migrations: '0021_migrate_to_bullseye', before migration 0022_php73_to_php74_pools.
Error: Run these migrations: '0021_migrate_to_bullseye', before migration 0023_postgresql_11_to_13.
Warning: Migration 0024_rebuild_python_venv has to be run manually. Please go to Tools → Migrations on the webadmin page, or run `yunohost tools migrations run`.

J’ai tenté de résoudre la situation avec cette commandes :

# yunohost tools migrations run 0021_migrate_to_bullseye
Info: Running migration 0021_migrate_to_bullseye...
Error: Migration 0021_migrate_to_bullseye did not complete, aborting. Error: The current Debian distribution is not Buster! If you already ran the Buster->Bullseye migration, then this error is symptomatic of the fact that the migration procedure was not 100% succesful (otherwise YunoHost would have flagged it as completed). It is recommended to investigate what happened with the support team, who will need the **full** log of the `migration, which can be found in Tools > Logs in the webadmin.
Info: The operation 'Run migrations' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220913-171229-tools_migrations_migrate_forward' to get help

J’ai aussi tenté directement les migrations php, postgresql ou le “rebuild-python-venv” :

# yunohost tools migrations run 0022_php73_to_php74_pools
Error: Run these migrations: '0021_migrate_to_bullseye', before migration 0022_php73_to_php74_pools.

# yunohost tools migrations run 0023_postgresql_11_to_13
Error: Run these migrations: '0021_migrate_to_bullseye', before migration 0023_postgresql_11_to_13.

# yunohost tools migrations run 0024_rebuild_python_venv
Error: Run these migrations: '0021_migrate_to_bullseye', before migration 0024_rebuild_python_venv.

Voici les logs :

# yunohost log share 20220913-171229-tools_migrations_migrate_forward
Info: This log is now available via https://paste.yunohost.org/raw/wukaregovi

J’ai de nouveau accès à la webadmin, je vais continuer d’investiguer.

Voici le log complet de la migration vers Debian Bullseye :

# yunohost log share  20220904-190529-tools_upgrade 
Info: This log is now available via https://paste.yunohost.org/raw/uqocuyipem

La première erreur (qui se répète un moment) :

2022-09-04 19:05:36,875: INFO - + Err :1 http://debian.mirrors.ovh.net/debian bullseye/main amd64 libc6 amd64 2.31-13+deb11u3
2022-09-04 19:05:36,878: INFO - +   Erreur temporaire de résolution de « debian.mirrors.ovh.net »

Ce qui amène au final au fait qu’il ne sait pas télécharger les paquets :

2022-09-04 19:05:38,224: WARNING - E: Impossible de récupérer certaines archives, peut-être devrez-vous lancer apt-get update ou essayer avec --fix-missing ?

Après la tentative de migration, j’ai eu un problème avec les DNS. Il n’y avait plus que nameserver 127.0.0.1 dans /etc/resolv.conf, j’ai remis les DNS de FDN. Je ne vois rien dans les logs qui permettrait de lui dire que la migration a finalement pu avoir lieu.

Bon… @Aleks m’a bien débloqué pour finir la mise à jour. J’ai eu tout un tas d’erreurs et petits problèmes que j’ai pu résoudre mais il reste quelques soucis.

  1. Yunohost considère que l’upgrade vers Bullseye n’a pas terminé. J’ai l’impression que tout est OK mais je ne vois pas comment lui dire “chut, c’est OK!”.

Il y a pas mal de trucs encore en cours en fait :

# yunohost tools migrations state
migrations: 
  0001_change_cert_group_to_sslcert: skipped
  0002_migrate_to_tsig_sha256: skipped
  0003_migrate_to_stretch: skipped
  0004_php5_to_php7_pools: skipped
  0005_postgresql_9p4_to_9p6: skipped
  0006_sync_admin_and_root_passwords: skipped
  0007_ssh_conf_managed_by_yunohost_step1: skipped
  0008_ssh_conf_managed_by_yunohost_step2: skipped
  0009_decouple_regenconf_from_services: skipped
  0010_migrate_to_apps_json: skipped
  0011_setup_group_permission: skipped
  0012_postgresql_password_to_md5_authentication: skipped
  0013_futureproof_apps_catalog_system: done
  0014_remove_app_status_json: done
  0015_migrate_to_buster: done
  0016_php70_to_php73_pools: done
  0017_postgresql_9p6_to_11: done
  0018_xtable_to_nftable: done
  0019_extend_permissions_features: done
  0020_ssh_sftp_permissions: done

Il voit quatre migrations “pending” :

# yunohost tools migrations list
migrations: 
  0: 
    description: Upgrade the system to Debian Bullseye and YunoHost 11.x
    disclaimer: None
    id: 0021_migrate_to_bullseye
    mode: manual
    name: migrate_to_bullseye
    number: 21
    state: pending
  1: 
    description: Migrate php7.3-fpm 'pool' conf files to php7.4
    disclaimer: None
    id: 0022_php73_to_php74_pools
    mode: auto
    name: php73_to_php74_pools
    number: 22
    state: pending
  2: 
    description: Migrate databases from PostgreSQL 11 to 13
    disclaimer: None
    id: 0023_postgresql_11_to_13
    mode: auto
    name: postgresql_11_to_13
    number: 23
    state: pending
  3: 
    description: Repair Python app after bullseye migration
    disclaimer: Following the upgrade to Debian Bullseye, some Python applications needs to be partially rebuilt to get converted to the new Python version shipped in Debian (in technical terms: what's called the 'virtualenv' needs to be recreated). In the meantime, those Python applications may not work. YunoHost can attempt to rebuild the virtualenv for some of those, as detailed below. For other apps, or if the rebuild attempt fails, you will need to manually force an upgrade for those apps.

Rebuilding the virtualenv will be attempted for the following apps (NB: the operation may take some time!): 
    - borg-env
    id: 0024_rebuild_python_venv
    mode: manual
    name: rebuild_python_venv
    number: 24
    state: pending

J’ai essayé de lire le script de mise à jour mais je n’arrive pas à voir où il a coincé et ce que je peux faire pour résoudre le problème. :thinking:

[edit: Je vois sur ce post une solution pour lui faire skipper “0021_migrate_to_bullseye”.

Je tente ça :

# yunohost tools migrations run 0021_migrate_to_bullseye --skip
Warning: Skipping migration 0021_migrate_to_bullseye...

Ça coince quand même plus loin.

# yunohost tools migrations run 0022_php73_to_php74_pools
Info: Running migration 0022_php73_to_php74_pools...
Synchronizing state of php7.3-fpm.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable php7.3-fpm
insserv: script noderige: service noderig already provided!
insserv: warning: current start runlevel(s) (empty) of script `php7.3-fpm' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `php7.3-fpm' overrides LSB defaults (0 1 6).
insserv: script noderige: service noderig already provided!
Removed /etc/systemd/system/multi-user.target.wants/php7.3-fpm.service.
Error: Migration 0022_php73_to_php74_pools did not complete, aborting. Error: Unknown service 'php7.4-fpm'
Info: The operation 'Run migrations' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220913-191501-tools_migrations_migrate_forward' to get help

# yunohost tools migrations run 0023_postgresql_11_to_13
Info: Running migration 0023_postgresql_11_to_13...
Info: No YunoHost app seem to require postgresql... Skipping!
Success! Migration 0023_postgresql_11_to_13 completed

# yunohost tools migrations run 0024_rebuild_python_venv --accept-disclaimer
Info: Running migration 0024_rebuild_python_venv...
Info: Now attempting to rebuild the Python virtualenv for `borg-env`
Success! Migration 0024_rebuild_python_venv completed

Pour php, voici ce que je viens de faire :

# sudo apt install php7.4-fpm

J’ai pu relancer la migration et cette fois c’est bon!


  1. Le serveur Matrix, Synapse, est planté.

J’ai tenté de le mettre à jour via la webadmin et … L’application a disparu de la liste des applications installées. :scream:

Voici les logs : logs de mise à jour de Synapse
(Il faut encore que je les lise pour essayer de comprendre ce qui coince.)

Ce problème me tracasse un peu… :worried: Je pense que le soucis vient du fait que la migration “0024_rebuild_python_venv” n’a pas pu se faire correctement.


  1. resolv.conf a été modifié à la main (voir plus haut). Le diagnostic ( :heart_eyes: ) indique sur quoi il doit pointer :

Le fichier /etc/resolv.conf doit être un lien symbolique vers /etc/resolvconf/run/resolv.conf lui-même pointant vers 127.0.0.1 (dnsmasq). Si vous souhaitez configurer manuellement les résolveurs DNS, veuillez modifier /etc/resolv.dnsmasq.conf.


  1. Les backups ne marchaient plus, le service Borg a l’air de fonctionner mais il va falloir que je vérifie que tout est bien carré à ce niveau là.

  1. Le diagnostic me dit que j’ai modifié le fichier /etc/mysql/my.cnf à la main alors que je suis sûr de ne pas y avoir touché.

J’ai essayé :

# yunohost tools regen-conf mysql --dry-run --with-diff 
# yunohost tools regen-conf mysql --force

Mais les commandes ne renvoient rien. Le fichier est bien là et il ne me semble pas bizarre.

Alors les problemes 1 et 2 sont liés, en particulier dans le log du restore de synapse:

WARNING - /usr/share/yunohost/helpers.d/php: ligne 237: php-fpm7.4 : commande introuvable

Normalement php7.4-fpm est installé à la fin de la migration, mais si tu l’as fini “à la main” alors ça ne s’est pas fait … Du coup faisons :

sudo apt install php7.4-fpm

Par contre tu auras peut-être d’autres apps php qui auront besoin de dépendances qui auraient normalement été installée à la fin de la migration et qu’il faudra installer à la main

Je viens de trouver pour php7.4-fpm. Merci de confirmer que l’installer à la main était la bonne chose à faire. :slight_smile:

Je n’avais pas réalisé le lien avec Synapse.

Du coup, est-ce possible de relancer la mise à jour de Synapse où elle a planté ? Je ne peux pas relancer l’upgrade depuis la webadmin parce que Synapse n’y apparait plus. J’ai hésité à réinstaller Synapse à la main mais j’ai peur de tout effacer.

Si je me trompe pas, dans le log il dit qu’il a pas supprimé les backups de Synapse :

2022-09-13 18:09:38,686: DEBUG - Due of the backup core only feature the data directory in '/home/yunohost.app/matrix-synapse' was not removed. It need to be removed manually to purge app user data.

Par contre il ne peut pas restaurer le backup parce que c’est une “version ancienne” de Yunohost. J’ai réessayé :

# yunohost backup restore synapse-pre-upgrade1 --apps synapse --force --debug
527  DEBUG initializing base actions map parser for cli
532  DEBUG loading actions map
535  DEBUG building parser...
556  DEBUG building parser took 0.020s
561  DEBUG acquiring lock...
608  DEBUG lock has been acquired
681  DEBUG loading python module yunohost.backup took 0.072s
681  DEBUG processing action [745518.1]: yunohost.backup.restore with args={'name': 'synapse-pre-upgrade1', 'system': None, 'apps': ['synapse'], 'force': True}
683  DEBUG action [745518.1] executed in 0.001s
684  DEBUG lock has been released
684  ERROR This backup archive can not be restored because it comes from a too-old YunoHost version.

Erf ben c’était le truc à faire … M’enfin c’est chelou car ce bug est censé être résolu, ou alors c’est une autre version de ce bug …

Bref le backup a normalement bien été fait en 11.x

Du coup ouvrons le fichier info.json correspondant. Normalement c’est genre :

sudo nano /home/yunohost.backup/archives/synapse-pre-upgrade1.json

(ou bien .info.json ?)

Ensuite il faut regarder et potentiellement corriger ce qu’il y a en face de from_yunohost_version

Voici le contenu du fichier :

# cat /home/yunohost.backup/archives/synapse-pre-upgrade1.info.json 
{"description": "", "created_at": 1663092136, "size": 262103839, "size_details": {"system": {}, "apps": {"synapse": 262102373}}, "apps": {"synapse": {"version": "1.59.0~ynh1", "name": "Synapse", "description": "Un serveur de messagerie instantan\u00e9 bas\u00e9 sur Matrix"}}, "system": {}, "from_yunohost_version": "BASH_XTRACEFD"}

À mon avis c’est le “BASH_XTRACEFD” qu’il digère pas ? :smiley:

J’ai essayé de regarder les autres fichiers dans le même dossier pour voir ce que je peux mettre pour “from_yunohost_version” mais ils ont tous “BASH_XTRACEFD”…

J’ai regardé sur mon autre serveur pour voir quelle était la bonne syntaxe et j’ai mis ça :

# cat /home/yunohost.backup/archives/synapse-pre-upgrade1.info.json 
{"description": "", "created_at": 1663092136, "size": 262103839, "size_details": {"system": {}, "apps": {"synapse": 262102373}}, "apps": {"synapse": {"version": "1.59.0~ynh1", "name": "Synapse", "description": "Un serveur de messagerie instantan\u00e9 bas\u00e9 sur Matrix"}}, "system": {}, "from_yunohost_version": "11.0.9.14"}

J’attends que la mise à jour de nextcloud se termine pour relancer un test de restauration de synapse.

Yep je pensais avoir résolu ce bug mais oui, c’est 11.bidule qu’il faut mettre

Désolé de te pointer un bug récalcitrant. :laughing:

J’ai relancé le restore de Synapse et ça semble bien se passer. :crossed_fingers:

[edit: la restauration de Synapse a bien fonctionné. J’ai voulu relancer l’upgrade et ça a, de nouveau, crashé.

# yunohost app upgrade synapse
Info: Now upgrading synapse...
Info: [....................] > Loading installation settings...
Info: [+...................] > Ensuring downward compatibility...
Info: [#++++++++...........] > Backing up the app before upgrading (may take a while)...
Warning: The user 'synapse' already exists
Warning: [Error] Upgrade failed.
Warning: insserv: script noderige: service noderig already provided!
Warning: This action broke dpkg/APT (the system package managers)... You can try to solve this issue by connecting through SSH and running `sudo apt install --fix-broken` and/or `sudo dpkg --configure -a`.
Warning: 753  This backup archive can not be restored because it comes from a too-old YunoHost version.
Warning: Uhoh ... Yunohost failed to restore the app to the way it was before the failed upgrade :|
Error: Could not upgrade synapse: An error occurred inside the app upgrade script
Info: The operation 'Upgrade the 'synapse' app' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220913-202306-app_upgrade-synapse' to get help
Warning: Here's an extract of the logs before the crash. It might help debugging the error:
Info: DEBUG - + app=synapse
Info: DEBUG - + [[ is_free_registration =~ (unprotected|protected|skipped)_ ]]
Info: DEBUG - + ynh_app_setting set synapse is_free_registration 0
Info: DEBUG - + '[' -z ']'
Info: DEBUG - ++ ynh_string_random --length=30
Info: DEBUG - ++ length=30
Info: DEBUG - ++ filter=A-Za-z0-9
Info: DEBUG - ++ dd if=/dev/urandom bs=1 count=1000
Info: DEBUG - ++ tr --complement --delete A-Za-z0-9
Info: DEBUG - ++ sed --quiet 's/\(.\{30\}\).*/\1/p'
Info: DEBUG - + synapse_user_app_pwd=**********
Info: DEBUG - + ynh_app_setting_set --app=synapse --key=synapse_user_app_pwd --value=**********
Info: DEBUG - + local _globalapp=synapse
Info: DEBUG - + app=synapse
Info: DEBUG - + [[ synapse_user_app_pwd =~ (unprotected|protected|skipped)_ ]]
Info: DEBUG - + ynh_app_setting set synapse synapse_user_app_pwd **********
Info: DEBUG - + yunohost user create synapse -f Synapse -l Application -d artanux.be -p **********
Info: WARNING - The user 'synapse' already exists
Info: DEBUG - You are now about to define a new user password. The password should be at least 8 characters long—though it is good practice to use a longer password (i.e. a passphrase) and/or to a variation of characters (uppercase, lowercase, digits and special characters).
Info: DEBUG - + ynh_exit_properly
Error: The operation 'Upgrade the 'synapse' app' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220913-202306-app_upgrade-synapse' to get help

Je suis en train de restaurer à nouveau…

Zblerg ça a l’air d’être du au code qui ne s’attends pas à ce que l’user Yunohost synapse existe déjà … potentiellement si ça re-crash tu peux essayer de le supprimer comme n’importe quel user yunohost “classique”

Ok, je vais regarder de ce côté là plus en détail.

je fatigue pour ce soir, il va être temps que j’aille dormir. Je continuerai demain.

@Aleks , un très grand merci! Ton aide est précieuse. (Et du peu que je vois sur le forum, tu aides vraiment un paquet de monde…)

1 Like

Il y a bien un /home/synapse/ :

$ sudo ls -al /home/synapse/
total 20
drwxrwxr-x+  2 synapse synapse 4096 Sep 13 18:03 .
drwxr-xr-x  28 root    root    4096 Sep 14 05:24 ..
-rw-r--r--   1 synapse synapse  220 Sep 13 18:03 .bash_logout
-rw-r--r--   1 synapse synapse 3526 Sep 13 18:03 .bashrc
lrwxrwxrwx   1 synapse synapse    6 Sep 13 18:03 media -> /media
lrwxrwxrwx   1 root    root      33 Sep 13 18:03 Multimedia -> /home/yunohost.multimedia/synapse
-rw-r--r--   1 synapse synapse  807 Sep 13 18:03 .profile

Par contre, je vois rien du côté de la webadmin, ni dans /etc/passwd :

$ cat /etc/passwd | grep synapse
matrix-synapse:x:993:993::/opt/yunohost/matrix-synapse:/usr/sbin/nologin

Dans les groupes :

$ groups synapse
synapse : synapse all_users mail.main xmpp.main nextcloud.main dokuwiki__2.main gitea.main borgserver.main borg.main synapse.main (...)

J’ai tenté de déplacer le dossier dans le home :

$ sudo mv /home/synapse/ /home/synapse-bkp

Mais ça n’a pas suffit. Je vais devoir faire un “deluser” mais j’ai un peu peur des possibles effets secondaires du truc…

J’ai essayé de supprimer l’utilisateur :

$ sudo deluser synapse
Removing user `synapse' ...
userdel: user 'synapse' does not exist
/usr/sbin/deluser: `/usr/sbin/userdel synapse' returned error code 6. Exiting.

$ sudo delgroup synapse
/usr/sbin/delgroup: `synapse' still has `synapse' as their primary group!

/usr/sbin/deluser: `/usr/sbin/userdel synapse' returned error code 6. Exiting.

$ sudo rm -rf /home/synapse/

Mais j’ai toujours la même erreur pendant l’upgrade :

$ sudo yunohost app upgrade synapse
Info: Now upgrading synapse...
(...)
Warning: The user 'synapse' already exists

J’ai à nouveau tout restauré…

Je suis en train de lire le script d’upgrade de synapse et je pense qu’en fait il créée un utilisateur “matrix-synapse” :

51          synapse_user="matrix-$app"

Je trouve aussi un utilisateur synapse dans yunohost :

$ sudo yunohost user list | grep -A 4 synapse
  synapse: 
    fullname: Synapse Application
    mail: synapse@artanux.be
    mailbox-quota: 0
    username: synapse

J’ai supprimé l’utilisateur:

$ sudo yunohost user delete synapse

On relance l’upgrade!

$ sudo yunohost app upgrade synapse
Info: Now upgrading synapse...
Info: [....................] > Loading installation settings...
Info: [+...................] > Ensuring downward compatibility...
Info: [#++++++++...........] > Backing up the app before upgrading (may take a while)...
Warning: FreshRSS failed requirements:
Warning: • pdo-mysql
Warning: Could not run script: /etc/yunohost/hooks.d/post_user_create/50-freshrss
Info: [#########+..........] > Upgrading dependencies...
Info: [##########++........] > Upgrading source files...
Info: '/opt/yunohost/matrix-synapse/.rustup' wasn't deleted because it doesn't exist.
Info: '/opt/yunohost/matrix-synapse/.cargo' wasn't deleted because it doesn't exist.
Info: [############........] > Updating synapse config...
Info: [############+.......] > Upgrading nginx web server configuration...
Info: [#############.......] > Configuring application...
Info: [#############.......] > Updating coturn config...
Info: [#############+......] > Upgrading systemd configuration...
Info: [##############++....] > Reconfiguring fail2ban...
Info: The service fail2ban has correctly executed the action reload-or-restart.
Info: [################+...] > Configuring permissions...
Warning: Additionnal URL 'artanux.be/.well-known/matrix' already removed in the additional URL for permission 'synapse.server_api'
Info: [#################+..] > Restarting synapse services...
Info: The service matrix-synapse has correctly executed the action restart.
Info: [####################] > Upgrade of synapse completed
Success! synapse upgraded
Success! Upgrade complete

Je ne sais pas trop pourquoi des messages concernant freshrss apparaissent mais du coup, j’ai installé php7.4-mysql en espérant que ça corrige le problème :

$ sudo apt install php7.4-mysql

Oui c’est parce qu’il y a un “hook” pour freshrss lorsqu’un compte est créé, et dans le cas très précis de synapse, il y a un user yunohost qui est créé pour des raisons, et du coup ça déclenche le hook freshrss

J’avais encore des problèmes avec DokuWiki (plus personne n’avait aucun accès, impossible de s’y connecter). Erreur : “No ACL setup yet! Denying access to everyone.”

Je me suis dis qu’il devait manquer une dépendance perdue dans l’upgrade. J’ai installé dokuwiki sur une autre URL et ça a résolu le problème. :grin:

Il me reste un problème avec etherpad.

J’ai espéré qu’en installant un autre etherpad sur une autre URL, ça réglerait le soucis mais pas cette fois. La nouvelle installation se porte comme un charme mais ça n’a pas réparé l’ancienne.

Voici à quoi ressemble la page :

Pour l’instant je ne trouve pas comment corriger la situation.

Quand j’essaye d’ouvrir un pad existant, j’ai plein d’erreurs 500 :

J’ai ouvert un post spécifique : [Etherpad] Mypad cassé?

Il me reste encore un problèmes avec les backups :

~$ sudo yunohost backup create -n auto_shaarli --method borg_app --apps shaarli
Info: Collecting files to be backed up for shaarli...
Info: Loading installation settings...
Info: Declaring files to be backed up...
Info: Backup script completed for shaarli. (YunoHost will then actually copy those files to the archive).
Info: Creating a backup archive from the collected files...
Info: The archive will contain about 152.1MiB of data.
Warning: Failed to format translated string 'backup_applying_method_custom': 'Calling the custom backup method '{method}'...' with arguments '()' and '{}, raising error: KeyError('method') (don't panic this is just a warning)
Warning: Failed to format translatable string 'backup_applying_method_custom': 'Calling the custom backup method '{method}'...' with arguments '()' and '{}', raising  error: KeyError('method') (don't panic this is just a warning)
Warning: /opt/borg-env/bin/python: can't open file '/opt/borg-env/bin/borg': [Errno 2] No such file or directory
Error: Could not run script: /etc/yunohost/hooks.d/backup_method/05-borg_app
Info: The operation 'Create a backup archive' could not be completed. Please share the full log of this operation using the command 'yunohost log share 20220921-111327-backup_create' to get help
Error: Custom backup method could not get past the 'backup' step

$ sudo yunohost log share 20220921-111327-backup_create
Info: This log is now available via https://paste.yunohost.org/raw/vupizawigo

Je vois que sur mon deuxième serveur, je n’ai pas la même chose dans /opt/borg-env/bin.

Serveur 1 :

$ ls -al /opt/borg-env/bin/
total 60
drwxr-xr-x 2 root root 4096 Sep 13 19:23 .
drwxr-xr-x 6 root root 4096 Sep 13 19:16 ..
-rw-r--r-- 1 root root 1892 Sep 13 19:16 activate
-rw-r--r-- 1 root root  841 Sep 13 19:16 activate.csh
-rw-r--r-- 1 root root 1981 Sep 13 19:16 activate.fish
-rw-r--r-- 1 root root 8834 Sep 13 19:16 Activate.ps1
-rwxr-xr-x 1 root root  396 Sep 13 19:23 borg
-rwxr-xr-x 1 root root  400 Sep 13 19:23 borgfs
-rwxr-xr-x 1 root root  238 Sep 13 19:16 easy_install
-rwxr-xr-x 1 root root  238 Sep 13 19:16 easy_install-3.9
-rwxr-xr-x 1 root root  229 Sep 13 19:16 pip
-rwxr-xr-x 1 root root  229 Sep 13 19:16 pip3
-rwxr-xr-x 1 root root  229 Sep 13 19:16 pip3.9
lrwxrwxrwx 1 root root   15 Sep 13 19:16 python -> /usr/bin/python
lrwxrwxrwx 1 root root    6 Sep 13 19:16 python3 -> python
lrwxrwxrwx 1 root root    6 Sep 13 19:16 python3.9 -> python

Serveur 2 :

$ ls -al /opt/borg-env/bin/
total 52
drwxr-xr-x 2 root root 4096 Sep 19 08:49 .
drwxr-xr-x 6 root root 4096 Sep 19 08:48 ..
-rw-r--r-- 1 root root 1892 Sep 19 08:49 activate
-rw-r--r-- 1 root root  841 Sep 19 08:49 activate.csh
-rw-r--r-- 1 root root 1981 Sep 19 08:49 activate.fish
-rw-r--r-- 1 root root 8834 Sep 19 08:49 Activate.ps1
-rwxr-xr-x 1 root root  238 Sep 19 08:49 easy_install
-rwxr-xr-x 1 root root  238 Sep 19 08:49 easy_install-3.9
-rwxr-xr-x 1 root root  229 Sep 19 08:49 pip
-rwxr-xr-x 1 root root  229 Sep 19 08:49 pip3
-rwxr-xr-x 1 root root  229 Sep 19 08:49 pip3.9
lrwxrwxrwx 1 root root   15 Sep 19 08:48 python -> /usr/bin/python
lrwxrwxrwx 1 root root    6 Sep 19 08:48 python3 -> python
lrwxrwxrwx 1 root root    6 Sep 19 08:48 python3.9 -> python

[edit: J’ai ouvert un post spécifique.

Ça ressemble à un problème avec le venv de borg qui ne s’est pas passé correctement …

Une façon de s’en sortir peut être de forcer l’upgrade de borg, ce qui devrait reconstruire le venv:

sudo yunohost app upgrade borg --force
1 Like

Merci @Aleks, je tente ça !

$ sudo yunohost app upgrade borg --force
Info: Now upgrading borg...
Info: [++..................] > Backing up the app before upgrading (may take a while)...
Info: [##++................] > Ensuring downward compatibility...
Info: [####++..............] > Upgrading dependencies...
Info: [######++............] > Configuring system user...
Info: [########+++.........] > Upgrading borgbackup...
Info: Installing/compiling borg, this may take some time...
Info: [###########++.......] > Setting up backup method...
Warning: File /etc/yunohost/hooks.d/backup_method/05-borg_app has been manually modified since the installation or last upgrade. So it has been duplicated in /var/cache/yunohost/appconfbackup//etc/yunohost/hooks.d/backup_method/05-borg_app.backup.20220928.114626
Warning: --- /var/cache/yunohost/appconfbackup//etc/yunohost/hooks.d/backup_method/05-borg_app.backup.20220928.114626	2022-04-09 13:14:41.033750053 +0000
Warning: +++ /etc/yunohost/hooks.d/backup_method/05-borg_app	2022-09-28 11:46:28.185122380 +0000
Warning: @@ -7,9 +7,9 @@
Warning:  BORG_PASSPHRASE="$(yunohost app setting $app passphrase)"
Warning:  repo="$(yunohost app setting $app repository)"   #$4
Warning:  if ssh-keygen -F "artanux.be" >/dev/null ; then
Warning: -    BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -p 12345 -oStrictHostKeyChecking=yes "
Warning: +    BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=yes "
Warning:  else
Warning: -    BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -p 12345 -oStrictHostKeyChecking=no "
Warning: +    BORG_RSH="ssh -i /root/.ssh/id_${app}_ed25519 -oStrictHostKeyChecking=no "
Warning:  fi
Warning:  do_need_mount() {
Info: [#############++.....] > Upgrading systemd configuration...
Info: [###############++...] > Integrating service in YunoHost...
Info: [####################] > Upgrade of borg completed
Success! borg upgraded
Success! Upgrade complete

(Le port “12345” n’est pas celui que j’utilise.)

$ ls -al /opt/borg-env/bin/
total 56
drwxr-xr-x 2 root root 4096 Sep 28 11:46 .
drwxr-xr-x 6 root root 4096 Sep 28 11:46 ..
-rw-r--r-- 1 root root 1892 Sep 28 11:39 activate
-rw-r--r-- 1 root root  841 Sep 28 11:39 activate.csh
-rw-r--r-- 1 root root 1981 Sep 28 11:39 activate.fish
-rw-r--r-- 1 root root 8834 Sep 28 11:39 Activate.ps1
-rwxr-xr-x 1 root root  220 Sep 28 11:46 borg
-rwxr-xr-x 1 root root  220 Sep 28 11:46 borgfs
-rwxr-xr-x 1 root root  229 Sep 28 11:39 pip
-rwxr-xr-x 1 root root  229 Sep 28 11:39 pip3
-rwxr-xr-x 1 root root  229 Sep 28 11:39 pip3.9
lrwxrwxrwx 1 root root    7 Sep 28 11:39 python -> python3
lrwxrwxrwx 1 root root   16 Sep 28 11:39 python3 -> /usr/bin/python3
lrwxrwxrwx 1 root root    7 Sep 28 11:39 python3.9 -> python3
-rwxr-xr-x 1 root root  216 Sep 28 11:39 wheel

Ça semble bon! Borg est à nouveau au bon emplacement.

J’ai à nouveau rajouté le port dans le bon fichier :

$ sudo vim /etc/yunohost/hooks.d/backup_method/05-borg_app
(...)

Et puis relancer le service:

$ sudo systemctl start borg 

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