[22:52:31]
<Jochen> Maybe this issue is related: https://github.com/YunoHost/issues/issues/2835
[22:52:32]
<Jochen> ---
English:
Hi! Just hit a reproducible issue with migration 0036_migrate_to_trixie on YunoHost 13.0.6 (Debian 13.6) — seems to match other reports on the forum, sharing in case it helps.
Symptom: `yunohost tools migrations list` shows 0036_migrate_to_trixie, 0037_postgresql_15_to_17 and 0038_rebuild_python_venv_in_trixie all stuck as `pending`, even though the system is already fully on Debian 13.6 / YunoHost 13.0.6, with only postgresql-17 installed (no postgresql-15 left). Running `yunohost tools migrations run` fails immediately with:
YunohostError: The current Debian distribution is not Bookworm! If you already
ran the Bookworm -> Trixie migration, then this error is symptomatic of the
fact that the migration procedure was not 100% successful...
Likely root cause (from reading m0036_migrate_to_trixie.py): `_write_migration_state(self.id, "done")` is only called near the very end of run(), after the apt full-upgrade steps that restart core services (incl. sshd). If the SSH session/process gets interrupted during that window (a known risk when not running inside tmux/screen), the underlying OS upgrade completes fine but the migration state never gets persisted as done. Next run, check_assertions() then hard-fails because the system is no longer on Bookworm.
Workaround: `sudo yunohost tools migrations run 0036_migrate_to_trixie --skip`, then `sudo yunohost tools migrations run` (0037 is a safe no-op since postgresql-15 isn't installed, 0038 rebuilds the venvs).
Suggestion: could check_assertions() detect "system already fully on Trixie + yunohost 13.x" and self-heal by marking the migration done, instead of hard-failing and requiring a manual --skip? Happy to share the full log if useful.
---
Français :
Salut ! Je viens de tomber sur un problème reproductible avec la migration 0036_migrate_to_trixie sous YunoHost 13.0.6 (Debian 13.6) — ça semble correspondre à d'autres retours sur le forum, je partage au cas où.
Symptôme : `yunohost tools migrations list` affiche 0036_migrate_to_trixie, 0037_postgresql_15_to_17 et 0038_rebuild_python_venv_in_trixie tous bloqués en `pending`, alors que le système est déjà entièrement en Debian 13.6 / YunoHost 13.0.6, avec uniquement postgresql-17 installé (plus de postgresql-15). Lancer `yunohost tools migrations run` échoue immédiatement avec :
YunohostError: The current Debian distribution is not Bookworm! If you already
ran the Bookworm -> Trixie migration, then this error is symptomatic of the
fact that the migration procedure was not 100% successful...
Cause probable (d'après la lecture de m0036_migrate_to_trixie.py) : `_write_migration_state(self.id, "done")` n'est appelé que tout à la fin de run(), après les étapes apt full-upgrade qui redémarrent des services critiques (dont sshd). Si la session SSH / le processus est interrompu pendant cette fenêtre (risque connu si on ne tourne pas dans tmux/screen), la mise à niveau du système se termine correctement mais l'état de la migration n'est jamais enregistré comme « done ». Au lancement suivant, check_assertions() échoue alors car le système n'est plus sous Bookworm.
Contournement : `sudo yunohost tools migrations run 0036_migrate_to_trixie --skip`, puis `sudo yunohost tools migrations run` (0037 ne fait rien en toute sécurité car postgresql-15 n'est pas installé, 0038 reconstruit les venvs).
Suggestion : est-ce que check_assertions() pourrait détecter « système déjà entièrement sous Trixie + yunohost 13.x » et se réparer automatiquement en marquant la migration comme terminée, plutôt que d'échouer et d'exiger un --skip manuel ? Je peux partager le log complet si besoin.
[22:52:51]
<orhtej2> > <@lauwcost:matrix.org> Hello. I tried upgrade to 2.15 but I have an error too ([https://paste.yunohost.org/raw/unemosuvoc](https://paste.yunohost.org/raw/unemosuvoc). Thanks for help.
lol it's a catch 22, now it requirea a +1 version 🤷
[22:52:51]
<orhtej2> > <@lauwcost:matrix.org> To make sure I understand: I'm waiting for the next version to be pushed, right?
Yes, most probably package fix
[22:52:52]
<lauwcost> "Dependency API requires version 1.0.16, but api 1.0.16 requires Grav 2.0.16 (you have 2.0.15). Update Grav first, then try again"
[22:52:52]
<lauwcost> Ok, I found how to redirect. You have to go to the main domain and this is where you can choose the default app to reset. I hadn't found it at first. Sorry for the noise.
[22:53:14]
<lauwcost> "Dependency API requires version 1.0.16, but api 1.0.16 requires Grav 2.0.16 (you have 2.0.15). Update Grav first, then try again"
[22:53:15]
<lauwcost> To make sure I understand: I'm waiting for the next version to be pushed, right?
[22:53:15]
<lauwcost> Thank you.
[23:21:47]
<DrPi> Pas bête. J'essaie ça ce soir.
Merci
[23:22:44]
<lauwcost> Bonjour à toutes et tous. Mon Yunohost sur ordinateur portable fonctionne très bien depuis plusieurs mois. Néanmoins récemment, je ne parviens pas à mettre à jour l'appli Grav. Il semble y avoir un problème de version de dépendance sous-jacent mais je ne sais pas le résoudre. Le log : [https://paste.yunohost.org/raw/ronegorawo](https://paste.yunohost.org/raw/ronegorawo). Merci pour toute l'aide que vous pourrez m'apporter.
[23:22:45]
<orhtej2> > <@lauwcost:matrix.org> Bonjour à toutes et tous. Mon Yunohost sur ordinateur portable fonctionne très bien depuis plusieurs mois. Néanmoins récemment, je ne parviens pas à mettre à jour l'appli Grav. Il semble y avoir un problème de version de dépendance sous-jacent mais je ne sais pas le résoudre. Le log : [https://paste.yunohost.org/raw/ronegorawo](https://paste.yunohost.org/raw/ronegorawo). Merci pour toute l'aide que vous pourrez m'apporter.
Try upgrading again now, I've pushed 2.15
[23:22:49]
<lauwcost> Thank You orhtej2. If I try to update with graphic window, he writes "Grav (grav) de 1.7.53~ynh1 à 2.0.14~ynh1". How to see 2.0.15 ?
[23:22:57]
<lauwcost> Thank you very much. I will try later.
[23:22:59]
<Thomas> The update will appear in the next few minutes/hours
[23:23:54]
<orhtej2> synapse
[23:24:05]
<orhtej2> element-call is just a 'dumb' webui
[23:24:09]
<BH3Panzer> aaah, ok
[23:24:11]
<BH3Panzer> thx very much, force-upgrading fixed the IP address !!!
[23:24:17]
<orhtej2> Thank Josue 😅
[23:25:05]
<Hamano> Hello there !
Sorry to bother.
I have installed the koffan application, but the service won't start.
Here's the YunoPaste : https://paste.yunohost.org/botebabife.
There's multiple entry because I tried several time to start the service.
Thanks for your interest 🙏
[23:25:13]
<tituspijean> @hamano:koko-matcha.fr hi, for once errors are crystal clear :)
Can you try force-upgrading the app with the following patch? It enables the binary build with CGO.
`yunohost app upgrade koffan -u https://github.com/YunoHost-Apps/koffan_ynh/tree/cgo -F`
[23:25:44]
<DrPi> Hello, J'ai un problème avec la mise à jour de gitlab. J'ai eu un plantage serveur avec système de fichier corrompu et réparé avec fsck. Le problème est peut-être lié à ça. La mise à jour de gitlab n'arrive pas à faire le backup pré-installation. Gitlab n'est plus fonctionnel après une tentative de mise à jour. Les logs sont ici : https://paste.yunohost.org/raw/lilugovoze Qu'est-ce que je peux faire pour résoudre le problème ?
[23:25:56]
<kayou> DrPi: Salut, la derniere mise a jour fonctionnelle date de quand?
[23:26:06]
<kayou> bizarre je pensais l'avoir corrige ca
> 2026-08-08 09:07:37,089: WARNING - Errno::EACCES: Permission denied - last_gitlab_backup.tar (Errno::EACCES)
je peux avoir le resultat de
```bash
sudo ls /var/opt/gitlab/backups/ -la
```
[23:26:20]
<kayou> et de ca temps qu'on y est:
```bash
sudo gitlab-ctl status
```
[23:26:39]
<Hamano> Thanks for your answer ! Sadly, seems like something didn't worked 😥
https://paste.yunohost.org/raw/gotatecuta
[23:26:56]
<tituspijean> no worries
can you share the output of `apt search ^gcc$` ?
[23:28:03]
<Hamano> `sudo apt search ^gcc$
En train de trier... Fait
Recherche en texte intégral... Fait
gcc/oldstable 4:12.2.0-3 amd64
compilateur C GNU`
[23:28:23]
<Hamano> 'sudo apt search ^gcc$'
'En train de trier... Fait'
'Recherche en texte intégral... Fait'
'gcc/oldstable 4:12.2.0-3 amd64'
' compilateur C GNU'
[23:28:33]
<Hamano> `sudo apt search ^gcc$`
`En train de trier... Fait`
`Recherche en texte intégral... Fait`
`gcc/oldstable 4:12.2.0-3 amd64`
`compilateur C GNU`
[23:29:16]
<tituspijean> OK, try again the upgrade command, I have added the gcc dependency
[23:30:00]
<DrPi> Sortie de `sudo ls /var/opt/gitlab/backups/ -la`
```
total 37704
drwx------ 2 git root 4096 Aug 8 09:07 .
drwxr-xr-x 22 root root 4096 Aug 8 08:50 ..
-r-------- 1 git git 38594560 Jun 23 22:02 last_gitlab_backup.tar
```
[23:30:31]
<DrPi> Sortie de `sudo gitlab-ctl status`
```
run: alertmanager: (pid 3323) 4845s; run: log: (pid 3316) 4845s
run: gitaly: (pid 3346) 4845s; run: log: (pid 3344) 4845s
run: gitlab-exporter: (pid 3334) 4845s; run: log: (pid 3330) 4845s
run: gitlab-kas: (pid 3336) 4845s; run: log: (pid 3329) 4845s
run: gitlab-pages: (pid 3337) 4845s; run: log: (pid 3325) 4845s
run: gitlab-workhorse: (pid 3335) 4845s; run: log: (pid 3321) 4845s
run: logrotate: (pid 19713) 1245s; run: log: (pid 3314) 4845s
run: nginx: (pid 3341) 4845s; run: log: (pid 3340) 4845s
run: node-exporter: (pid 3324) 4845s; run: log: (pid 3313) 4845s
run: postgres-exporter: (pid 3327) 4845s; run: log: (pid 3322) 4845s
run: postgresql: (pid 3331) 4845s; run: log: (pid 3326) 4845s
run: prometheus: (pid 3338) 4845s; run: log: (pid 3332) 4845s
run: puma: (pid 3318) 4845s; run: log: (pid 3315) 4845s
run: redis: (pid 3328) 4845s; run: log: (pid 3320) 4845s
run: redis-exporter: (pid 3333) 4845s; run: log: (pid 3319) 4845s
run: sidekiq: (pid 3339) 4845s; run: log: (pid 3312) 4845s
```
Après desinstallation et restauration du dernier backup, Gitlab fonctionne. Après retentative de mise à jour, même problème. Les sorties des commandes sont faites après tentative de mise à jour, donc gitlab cassé.
[23:30:42]
<Hamano> it's working ! thanks a lot, you're the best ! 🙏
[23:30:55]
<kayou> ```bash
sudo rm /var/opt/gitlab/backups/last_gitlab_backup.tar
```
enlever l'ancien backup devrait suffire, pour corriger le backup et la mise a jour, mais si gitlab est encore casse, il faudrait sans doute voir pourquoi et comment il est casse
[23:31:58]
<DrPi> Je pense qu'il est cassé par la tentative de restauration après échec de l'upgrade.
[23:32:08]
<tituspijean> Great, enjoy the app :) We will push the fix for all once the PR is approved by the maintainer.
[23:32:32]
<Hamano> Okay ! Thanks for your responsiveness !
[23:32:44]
<kayou> tu peux essaye de mettre de cote le backup actuelle pour ne pas le perdre et de retester une mise a jour
[23:33:28]
<kayou> apres avoir fait
```
sudo rm /var/opt/gitlab/backups/last_gitlab_backup.tar
```
[23:34:20]
<DrPi> Je viens de d'essayer en supprimant le dernier backup dans l'interface de YuNoHost. Même problème.
J'essaie avec la suppression en ligne de commande.
[23:34:34]
<DrPi> Le backup est passé. L'upgrade est en cours...
[23:35:14]
<DrPi> L'upgrade est terminée. Gitlab m'a l'air parfaitement fonctionnel.
Merci beaucoup pour ton aide. Super efficace 😄
[23:35:25]
<kayou> pas de souci, hesite pas a me ping pour gitlab :)
[23:36:09]
<lauwcost> Hello. I tried upgrade to 2.15 but I have an error too ([https://paste.yunohost.org/raw/unemosuvoc](https://paste.yunohost.org/raw/unemosuvoc). Thanks for help.