[10:54:45]
<Yaeghs> Hello there. I've got a strange problem. I have two users in my instance. Let's say charles and viktor. I have roundcube. Charles can connect to Roundcube without any problem. But when wiktor connects, he takes a "Erreur de connexion au serveur de stockage, AUTHENTICATE PLAIN : Authentification failed".
[10:54:50]
<Yaeghs> I went to /var/log/mail.log and indeed, there's an authenticate plain error. But the username labeled for this error is charles
[10:54:51]
<Yaeghs> So, indeed, the authentification is wrong as I am trying to connect with viktor and not charles
[10:54:56]
<Yaeghs> Ah. I've found when writing. I had a cookie for Charles, so firefox tried to connect with this cookie instead doing it with the provided informations
[12:27:46]
<nojhan> Try FF containers when testing, that greatly helps avoiding this kind of issues.
[12:34:54]
<Chatpitaine Caverne> Yaeghs: Right, or FF profiles or delete site's cookies
[14:09:21]
<Aunisien> Je pense que l’on peut continuer en Français.
Je n’ai que Synapse et Synapse Admin d’installer sur mon instance Yunohost.
Dans les paramètres je ne vois rien de particulier en terme de droits.
[17:31:05]
<Chatpitaine Caverne> OK, Je supposerai que tout est à jour en dernière version ynh. Peut-être regader du côté des redirections de port si tous les ports sont présent ?
Sinon, reproduire l'anomalie et regarder dans les logs des services, en détail.
[19:29:55]
<tomlamo> Hi, does anyone know if there exists a `--no-remove-on-failure` option for `yunohost app upgrade`, like for `yunohost backup restore` ?
[19:30:01]
<Salamandar> i'm pretty sure there is yeah
[19:30:09]
<Salamandar> it's useful for debugging
[19:32:21]
<tomlamo> I see this :
```
-c, --continue-on-failure
Continue to upgrade apps even if one or more upgrade failed
```
But I don't understand if it's the same. It seems that if you upgrade many apps at the same time, it will continue upgrading other apps if one fails, but I don't think it will avoid removing and restoring the app if upgrade fails.
[19:32:33]
<Chatpitaine Caverne> It's the same, I already had to use it. It continues even in case of error. This is useful when an error occurs close to the end of the upgrade script. In my case it was the service start which failled, so I was able to correct the service error having all logs available and start it. The upgrade was then done.
[19:45:55]
<tomlamo> Ok thanks, I test it.
[19:45:55]
<tomlamo> It didn't work, service start failed, app was removed, and backup failed to restore again, for the same reason, service start failed...
[19:45:56]
<tomlamo> `sudo yunohost app upgrade peertube -c`
[19:45:57]
<Chatpitaine Caverne> Strange it worked for me.
I use the `--continue-on-failure` syntax cause I prefer such syntax. Maybe due to that, but extremly strange and fully uncertain.
I don't remember there was a yunohost upgrade since, so very strange it doesn't work.
[19:48:58]
<otm33> tomlamo: Can you share the logs ?
[20:11:14]
<tomlamo> https://paste.yunohost.org/raw/irizuqapoq
[20:11:15]
<orhtej2> sounds like a migration timeout, can you try with `--continue-on-failure` as suggested above?
[20:11:15]
<tomlamo> journalctl log error shows this :
```
avril 05 21:40:45 temp.local peertube[3313105]: "error": {
avril 05 21:40:45 temp.local peertube[3313105]: "stack": "Error: Could not load the \"sharp\" module using the linux-x64 runtime\nUnsupported CPU: Prebuilt binaries for linux-x64 require v2 microarchitecture\nPossible solutions:\n- >
avril 05 21:40:45 temp.local peertube[3313105]: "message": "Could not load the \"sharp\" module using the linux-x64 runtime\nUnsupported CPU: Prebuilt binaries for linux-x64 require v2 microarchitecture\nPossible solutions:\n- Ensur>
avril 05 21:40:45 temp.local peertube[3313105]: },
avril 05 21:40:45 temp.local peertube[3313105]: "stack": "Error: Could not load the \"sharp\" module using the linux-x64 runtime\nUnsupported CPU: Prebuilt binaries for linux-x64 require v2 microarchitecture\nPossible solutions:\n- En>
avril 05 21:40:45 temp.local peertube[3313105]: "exception": true,
avril 05 21:40:45 temp.local peertube[3313105]: "date": "Sun Apr 05 2026 21:40:45 GMT+0200 (heure d’été d’Europe centrale)",
avril 05 21:40:45 temp.local peertube[3313105]: "process": {
avril 05 21:40:45 temp.local peertube[3313105]: "pid": 3313105,
avril 05 21:40:45 temp.local peertube[3313105]: "uid": 984,
avril 05 21:40:45 temp.local peertube[3313105]: "gid": 984,
avril 05 21:40:45 temp.local peertube[3313105]: "cwd": "/var/www/peertube",
avril 05 21:40:45 temp.local peertube[3313105]: "execPath": "/opt/node_n/n/versions/node/22.22.2/bin/node",
avril 05 21:40:45 temp.local peertube[3313105]: "version": "v22.22.2",
avril 05 21:40:45 temp.local peertube[3313105]: "argv": [
avril 05 21:40:45 temp.local peertube[3313105]: "/opt/node_n/n/versions/node/22.22.2/bin/node",
avril 05 21:40:45 temp.local peertube[3313105]: "/var/www/peertube/dist/server"
avril 05 21:40:45 temp.local peertube[3313105]: ],
```
[20:11:16]
<tomlamo> Ok I try with --continue-on-failure, but seems to be the same as -c
[20:11:16]
<orhtej2> ahhh the infamous `sharp`, I have no solution for that
[20:11:16]
<otm33> Unsupported CPU
[20:13:29]
<orhtej2> speaking of arch, Funkwhale dropped 'illegal instruction' on me while upgrading to 2.0.1 🤷
Any official requirements for prebuilts?
[20:13:48]
<otm33> 🤷I can’t get this app to work (funkwhale)
[20:28:44]
<orhtej2> 1.4.x wfm, it's 2.0 that bumped the requirements I guess 🤷
[20:28:45]
<Chatpitaine Caverne> `journalctl --quiet --no-hostname --no-pager --lines=20 --unit=peertube`
By the way, looking in the upgrade log. Would it be possible to put the full log of the service insteed of 20 lines. Cause in case of error, we have no more access to the log and last time the interresting line was 1 line before the 20 given lines. Murphy law in action.
[20:29:10]
<tomlamo> I confirm that I get the same behavior with --continue-on-failure, upgrade fail, app removed, backup restored.
[20:31:26]
<tomlamo> Thanks for your help, but there is no urgency for me, and backup is working, so I stop here for tonight. I will open an issue on app package.
[20:32:43]
<tomlamo> I would just find very usefull to get a --no-remove-on-failure on yunohost app upgrade command.
[20:32:43]
<Chatpitaine Caverne> Indeed, without that, I would not have been able to migrate my Peertube during a server change.