sudo apt install gcc-8-base
Ah oui !
root@ynh:~# apt install gcc-8-base
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
The following packages will be REMOVED:
libgcc1
The following packages will be upgraded:
gcc-8-base
1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 195 kB of archives.
After this operation, 165 kB disk space will be freed.
Do you want to continue? [Y/n]
Get:1 Index of /raspbian bullseye/main armhf gcc-8-base armhf 8.4.0-7+rpi1 [195 kB]
Fetched 195 kB in 0s (413 kB/s)
Reading changelogs… Done
(Reading database … 69021 files and directories currently installed.)
Removing libgcc1:armhf (1:8.3.0-6+rpi1) …
(Reading database … 69020 files and directories currently installed.)
Preparing to unpack …/gcc-8-base_8.4.0-7+rpi1_armhf.deb …
Unpacking gcc-8-base:armhf (8.4.0-7+rpi1) over (8.3.0-6+rpi1) …
Setting up gcc-8-base:armhf (8.4.0-7+rpi1) …
Processing triggers for libc-bin (2.31-13+rpt2+rpi1+deb11u3) …
Finalement, je m’attendais à bien pire pour cette mise à niveau.
Super boulot franchement, merci 
First of all, a big thank you to the team, the migration worked almost perfectly. I’ve been working on the following problem and would like to share my solution in case anyone else finds their way here (via Google search) in the hope of finding a solution:
My Mailman3 installation was no longer functional after the upgrade (could not connect to server: Connection refused).
While troubleshooting, I saw that the postgresql service (in the Web Admin area) was also not working and was the basis of the error: postgresql was “inactive” and had not been active for “52 years”. Although service postgresql status showed that the service was running, it was not active in the GUI even after a restart and netstat -tulpn | grep 5432 did not show a listening service.
Checked various things with postgresql (no conflicting postgresql-11 installed, etc.) and then removed postgresql with apt-get --purge remove postgresql postgresql-* without deleting the directories (there is a prompt, asking if you want to do so)! This did all not help.
My Solution (not striaghtforward but working) was:
- remove postgresql
apt-get --purge remove postgresql postgresql-*and delete the postgresql dirs as the prompt asks you to do. - reinstall with
apt-get install post postgresql-13. Postgresql is now functional and listens to port 5432 but mailman3 connection to postgresql is now broken (FATAL: password authentication failed for user "mailman3_app"). Thus the mailman service still doesn’t start. - uninstall mailman3 via GUI
- install backup version of mailman3 via GUI. Now you can log in, but Mails are not delivered and trying to create a new list breaks the installation again.
-
Here was the trick: I went through the post-install steps and when creating the superuser (
python3 manage.py createsuperuser) it prompted me with:Your project may not work properly until you apply the migrations for app(s): admin, auth, hyperkitty, postorius. Run 'python manage.py migrate' to apply them.. Doing that and/or the following commandmailman aliasesdid solve the problem for me! Mailman is back and running.
Sorry if the description is not detailed enough. I am not expert enough to say what exactly was the problem, maybe some of you do and maybe this can be added to “known issues”…?
Have a nice day!
Jakob
After fixing the grub-pc issue, the migration went fast and smooth. Thank you for the wonderful work.
I 'm asking, doesn’t it need a reboot after the migration?
Bonjour,
J’ai mon serveur hébergé sur un RPI4 4Go. J’ai fait toutes mes mises à jour et lancé la migration ce matin.
C’est un echec. D’après ce que je peux lire ici cela viendrait du fait que j’avais installé Yunohost à partir d’une debian avec Desktop. A priori ce serait les pacquets lié au DE qui ne pourraient passer la mise à jour.
A part repartir from scratch que puis je faire ?
merci par avance
Bon j’ai peut être fait une bêtise:
j’ai essayé:
sudo apt-get update && sudo apt-get upgrade
Du coup j’ai l’impression d’avoir migrer en Bulleyes sans les outils Yunohost ce qui fait qu j’ai un systeme coincé entre deux.
sudo yunohost --version
yunohost:
repo: stable
version: 4.4.2.14
yunohost-admin:
repo: stable
version: 4.4.1
moulinette:
repo: stable
version: 4.4.1
ssowat:
repo: stable
version: 4.4.1
lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
Si je tente une mise à jour j’ai ceci
J’ai aussi YunoHost basé sur une Debian avec desktop car mon serveur était aussi media center, et la MaJ s’est déroulée sans soucis.
(Je sais que ça n’aide pas forcément comme information)
@Guygoye : naivement je ferais un apt remove libgirepository-1.0-1 libldb1 --dry-run pour essayer de comprendre à quoi sont liés ces paquets (NB: met bien le --dry-run)
Bonjour,
quant à moi, j’héberge Yunohost à la maison sur un RPi3B+.
J’ai fait toutes les mises à jour et lancé la migration.
Mon 1er soucis est un manque de place sur /boot
En effet la partition (FAT32) ne fait que ~40Mo et il en faut au moins 70 pour lancer la migration (j’ai nettoyé aussi avec apt autoremove).
J’ai suivi ce tuto : Resizing the boot partition in linux - Linux Windows and android Tutorials mais je me retrouve avec une partition de 5120Mo (taille physique) mais avec un contenu de 40Mo (puisque la copie de l’ancienne partition vers la nouvelle est fait avec dd).
gparted, fatresize échouent…
J’ai finalement copié le contenu de /boot à la main, tenté un reboot et c’est reparti, un miracle ? (je vois des erreurs -dirty bit- sur cette nouvelle partition /boot, y-a-t-il un moyen de corriger ça ?).
Ensuite j’ai lancé la migration, et là j’ai d’autres erreurs, les logs complets.
Merci à la communauté pour ses efforts pour le dev et le support, sans relâche. C’est bô 
Heeeeeu, wut x_X 5120 Mo ?
Dirty bit ? 
Mais du coup il faudrait avoir le message d’erreur précis … (ou genre le log complet, là je sais pas du tout où tu vois ça …)
unable to install new version of '/bin/uncompress': Structure needs cleaning
ça a l’air pas ouf comme erreur, genre les posts sur internet qui en parlent disent que c’est symptomatique d’un système de fichier (ou bien juste quelques fichiers?) en caraffe, et recommande de :
sudo fsck.ext4 /dev/sda[NUMBER]
avec [NUMBER] le numéro de ta partition principale, que tu peux trouver par exemple avec df -h ou lsblk -f (en supposant que celle-ci soit bien de type ext4)
Heeeeeu, wut x_X 5120 Mo ?
je m’emballe ! c’est 512 Mo
Dirty bit ?
la commande
sudo fsck -f /dev/sda1
me retourne :
fsck from util-linux 2.33.1
fsck.fat 4.1 (2017-01-24)
0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
ça a l’air pas ouf comme erreur, genre les posts sur internet qui en parlent disent que c’est symptomatique d’un système de fichier (ou bien juste quelques fichiers?) en caraffe
l’échec de l’installation n’a rien à voir avec la migration, c’est ça ?
Mouarf j’imagine que le fsck ne peut pas vraiment se faire tant que le système est monté … Est-ce que tu as moyen de mettre le disque (ou carte SD?) sur une autre machine et lancer le fsck depuis là ?
Salut @Aleks,
merci pour la réponse, voici le retour:
sudo apt remove libgirepository-1.0-1 libldb1 --dry-run
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
libtool : Dépend: libc6-dev mais ne sera pas installé ou
libc-dev
nextcloud-ynh-deps : Dépend: smbclient mais ne sera pas installé
E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état.
l’option --dry-run sert à quoi ?
À juste simuler ce que apt ferait
Du coup tentons plutôt :
sudo apt install libgirepository-1.0-1- libldb1- smbclient libtool --dry-run
(note que maintenant on appelle “install”, mais certains paquets sont suffixés par - pour demander leur désinstallation)
Mouarf j’imagine que le fsck ne peut pas vraiment se faire tant que le système est monté … Est-ce que tu as moyen de mettre le disque (ou carte SD?) sur une autre machine et lancer le fsck depuis là ?
en effet, je retire le disque dur du RPi pour ce genre de manip.
je viens de lancer la commande que tu indiquais :
sudo fsck.ext4 /dev/sda[NUMBER]
il y a bcp bcp d’erreurs : “le compteur de référence de l’i-noeud xxxxx est 1, devrait être 2. Corriger ?”
et aussi : “Le décompte des blocs libres est erroné pour le groupe n°n (xxx, décompté=0).
Corriger ?”
j’ai tout corrigé.
En revanche Yunohost n’a pas redémarré, je vais investiguer…
Même réponse:
sudo apt install libgirepository-1.0-1- libldb1- smbclient libtool --dry-run
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
libtool est déjà la version la plus récente (2.4.6-15).
libtool passé en « installé manuellement ».
Certains paquets ne peuvent être installés. Ceci peut signifier
que vous avez demandé l'impossible, ou bien, si vous utilisez
la distribution unstable, que certains paquets n'ont pas encore
été créés ou ne sont pas sortis d'Incoming.
L'information suivante devrait vous aider à résoudre la situation :
Les paquets suivants contiennent des dépendances non satisfaites :
moulinette : Dépend: python3-yaml mais ne sera pas installé
Dépend: python3-gevent-websocket mais ne sera pas installé
yunohost : Dépend: python3-lexicon mais ne sera pas installé
E: Erreur, pkgProblem::Resolve a généré des ruptures, ce qui a pu être causé par les paquets devant être gardés en l'état.
Beh pour le coup non c’est pas du tout pareil 
D’ailleurs c’est mieux que ce que j’espérait
Du coup peut-être qu’avec ça ça devrait être mieux encore:
sudo apt install libgirepository-1.0-1- libldb1- smbclient libtool python3-lexicon python3-gevent-websocket python3-yaml --dry-run
@Guygoye : oui, du coup on peut enlever le --dry-run. Par contre attention, ça semble désinstaller les trucs de gnome / LXDE … Même si je pense qu’après la mise à jour ce sera possible de le réinstaller
sudo apt install libgirepository-1.0-1- libldb1- smbclient libtool python3-lexicon python3-gevent-websocket python3-yaml
Ca y est après un bon moment de mise à jour, suivie d’un
sudo yunohost tools upgrade system
Je suis arrivé ici:
sudo yunohost --version
yunohost:
repo: stable
version: 11.0.9.13
yunohost-admin:
repo: stable
version: 11.0.10
moulinette:
repo: stable
version: 11.0.9
ssowat:
repo: stable
version: 11.0.9
Je crois qu’on est bon non?
Je dois encore faire la mise à jour des applications