YunoHost 11.0 (Bullseye) release / Sortie de YunoHost 11.0 (Bullseye)

Okay, I’m stuck. …

I removed Mobilizon Application and tried to do the migration, but obviously removing the database failed and because of this the migrations still fails. :frowning:

There are some other applications failing (searx, synapse, lufi, moodle), but I think this is mostly because of postgresql or php7.3.

So I’ll have to wait and fix it later.

@chmeyer : can you try to sudo apt install postgresql-postgis ?

Qu’est-ce que tu veux dire par “la migration ne se fait pas” ? Quelle migration ? Est-ce que tu peux partager le log complet ?

pour tester les dernières mises au point, je suis repartie d’une sauvegarde en 4.4.2
Elle est bien passée en 4.4.2.3, puis j’ai lancé la migration qui échoue. voici le log
c’est exactement ce qui ce passait avant cette étape

1 Like

Donc c’est le probleme de libc6 et non pas le probleme de dhcpcd … J’essaye de patcher la migration dès que j’ai 2 minutes de tranquilles pour coder …

3 Likes

Courage :sweat_smile:

(et merci pour le travail de support qui déchire :clap:)

3 Likes

arf, j’ai mis à jour le lien vers le bon post dans mon premier message, du coup je ne t’ai pas aiguillé sur le bon pb… :confused:

encore merci pour tout (le boulot, l’assistance, la présence, … :slight_smile: )
je le laisse online pour le moment

I definitely feel sorry for poor @Aleks. I think we need to collect vitamins for his brain for him

Der arme @Aleks tut mir eindeutig leid. Ich glaube, wir müssen für ihn sammeln Vitaminstoffe für sein Gehirn :roll_eyes: :kissing: :smiling_face:

1 Like

@Aleks

I did (and un-did) it before already, but here is what it actually says (short: nothing changed):

# apt install postgresql-postgis
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package postgresql-postgis is a virtual package provided by:
  postgresql-11-postgis-2.5 2.5.1+dfsg-1
  postgresql-13-postgis-3 3.1.1+dfsg-1
You should explicitly select one to install.

E: Package 'postgresql-postgis' has no installation candidate

Okay, then let’s name it explicitly:

# apt install postgresql-11-postgis-2.5 postgresql-13-postgis-3
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
postgresql-11-postgis-2.5 is already the newest version (2.5.1+dfsg-1).
postgresql-11-postgis-2.5 set to manually installed.
The following NEW packages will be installed:
  postgresql-13-postgis-3 postgresql-13-postgis-3-scripts
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 4,452 kB of archives.
After this operation, 37.1 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 postgresql-13-postgis-3-scripts all 3.1.1+dfsg-1 [1,085 kB]
Get:2 http://deb.debian.org/debian bullseye/main amd64 postgresql-13-postgis-3 amd64 3.1.1+dfsg-1 [3,366 kB]
Fetched 4,452 kB in 0s (44.1 MB/s)             
Selecting previously unselected package postgresql-13-postgis-3-scripts.
(Reading database ... 79058 files and directories currently installed.)
Preparing to unpack .../postgresql-13-postgis-3-scripts_3.1.1+dfsg-1_all.deb ...
Unpacking postgresql-13-postgis-3-scripts (3.1.1+dfsg-1) ...
Selecting previously unselected package postgresql-13-postgis-3.
Preparing to unpack .../postgresql-13-postgis-3_3.1.1+dfsg-1_amd64.deb ...
Unpacking postgresql-13-postgis-3 (3.1.1+dfsg-1) ...
Setting up postgresql-13-postgis-3-scripts (3.1.1+dfsg-1) ...
update-alternatives: using /usr/share/postgresql/13/extension/postgis-3.control to provide /usr/share/postgresql/13/extension/postgis.control (postgresql-13-postgis.control) in auto mode
Setting up postgresql-13-postgis-3 (3.1.1+dfsg-1) ...
Processing triggers for postgresql-common (225) ...
Building PostgreSQL dictionaries from installed myspell/hunspell packages...
Removing obsolete dictionary files:
Updating coolwsd systemplate

and now try to migrate again:


# LC_ALL=C pg_upgradecluster -m upgrade 11 main
Restarting old cluster with restricted connections...
Notice: extra pg_ctl/postgres options given, bypassing systemctl for start operation
Stopping old cluster...
Creating new PostgreSQL cluster 13/main ...
/usr/lib/postgresql/13/bin/initdb -D /var/lib/postgresql/13/main --auth-local peer --auth-host md5 --encoding UTF8 --lc-collate en_US.UTF-8 --lc-ctype en_US.UTF-8
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/13/main ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Europe/Berlin
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

    pg_ctlcluster 13 main start

Ver Cluster Port Status Owner    Data directory              Log file
13  main    5433 down   postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log

/usr/lib/postgresql/13/bin/pg_upgrade -b /usr/lib/postgresql/11/bin -B /usr/lib/postgresql/13/bin -p 5432 -P 5433 -d /etc/postgresql/11/main -D /etc/postgresql/13/main
Finding the real data directory for the source cluster      ok
Finding the real data directory for the target cluster      ok
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for tables WITH OIDS                               ok
Checking for invalid "sql_identifier" user columns          ok
Creating dump of global objects                             ok
Creating dump of database schemas
                                                            ok
Checking for presence of required libraries                 fatal

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    loadable_libraries.txt

Failure, exiting
Error: pg_upgrade run failed. Logfiles are in /var/log/postgresql/pg_upgradecluster-11-13-main.1dey
Error during cluster dumping, removing new cluster
Cluster is not running.
Error: could not stop old cluster, please do that manually

and finaly:

# cat /var/log/postgresql/pg_upgradecluster-11-13-main.1dey/loadable_libraries.txt 
could not load library "$libdir/postgis-2.5": ERROR:  could not access file "$libdir/postgis-2.5": No such file or directory
In database: mobilizon
could not load library "$libdir/rtpostgis-2.5": ERROR:  could not access file "$libdir/rtpostgis-2.5": No such file or directory
In database: mobilizon
1 Like

Bonjour,
Migration réalisée sans problème aujourd’hui.
Bravo et merci à tous les contributeurs.

Juste quelques messages d’erreur apparaissent sur ma page d’accueil PIWIGO :

Deprecated: Invalid characters passed for attempted conversion, these have been ignored in /var/www/piwigo/include/template.class.php on line 215

Deprecated: Invalid characters passed for attempted conversion, these have been ignored in /var/www/piwigo/include/template.class.php on line 1024

Deprecated: Invalid characters passed for attempted conversion, these have been ignored in /var/www/piwigo/include/template.class.php on line 1024

Deprecated: Invalid characters passed for attempted conversion, these have been ignored in /var/www/piwigo/include/template.class.php on line 1899

@beelu : Version 4.4.2.4 should have a better detection and auto-patching for the libc6 / libgcc-8-dev hell. Though if you already ran the migration once, your sources.list now points to bullseye so you’ll need to manually tweak them to get backup to buster, then apt install yunohost=4.4.2.4, then retry the migration

1 Like

@Aleks j’ai “merdé” en cours de route donc reparti à zéro :stuck_out_tongue:
d’une 4.3.6.3 j’suis passé sur en 4.4.2.5.
La migration de 4.x.x vers 11.x ne passe pas, voici le log ,semble toujours venir de libc6

@beelu : :sob: Si jamais t’es dispo sur le chat et que ton instance est “jetable” ce serait cool de se faire un tmux ou un screen pour regarder le truc ensemble en interactif plutôt que de galérer à se synchro sur le forum. J’ai quelques idées supplémentaires que j’aimerais tester mais c’est galère sans avoir accès directement à un RPi sous Buster

1 Like

Hello,
en ce qui me concerne, cette mise à jour, appliquée sur une installation fraiche et un Raspberry 4 8Go, n’a plus générée d’erreurs bloquantes ou la disparition du réseau au redémarrage.
Par contre, la migration de l’application searx n’a pas été fonctionnelle (même avec yunohost app upgrade -F searx) et a nécessité une désinstallation puis une réinstallation.

Salut @Aleks , oui ça doit pouvoir se faire. Je me suis connecté au chat via kiwi sur le pc

Bonjour @Aleks le valeureux,

Voilà ce que donne # ls -l /var/log :

J’ai déplacé

-rw-r----- 1 root     root             13884 May  4  2020 fail2ban.log.1.gz-2020050713.backup
-rw-r----- 1 root     root            1468974 Nov 14  2021 mail.info.1.gz-2021111400.backup
-rw-r----- 1 root     root            1014391 Jun 26 00:00 mail.info.1.gz-2022062600.backup

dans /home mais pour tout ce que je fais, j’ai ce problème No space left on device même pour installer ncdu :

…et toutes les 10mn, je reçois un message d’injures de la part d’un petit diable Cron : YunoHost DynDNS update; sleep $((RANDOM%60)); ! ping -q -W5 -c1 ip.yunohost.org >/dev/null 2>&1 || test -e /var/run/moulinette_yunohost.lock || yunohost dyndns update >> /dev/null : :imp:

:face_with_diagonal_mouth:

1 Like

Je suis parvenu à trouver ce qui encombrait /var/log.

J’ai un sous-répertoire /avr/log/journal avec un nom composé de chiffres et de lettres illisibles, dans lequel j’ai des fichiers dépendant créés par systemd.

Le plus gros : -rw-r----- 1 root root 16777216 Aug 12 11:07 system@119965c3ab0b4454ac16003480225294-0000000000000001-0005e60942738168.journal

:crazy_face:

J’en ai 6 le même jour à la même heure :

-rw-r----- 1 root root 634880 Aug 11 15:33 system@3c6e9fba1ce549f9835ac7b83f6353f0-000000000000020a-0005e5ed3e718354.journal

Il a donc été généré quand j’ai fait le backup ou quand j’ai fait la migration.

J’ai viré les 6 journeaux du 11/08 le les 2 du 12.

Tout semble maintenant fonctionnel. J’accède aux apllis par le web, sauf que le hotspot bien qu’en activité sans erreurs au diagnostic, n’apparaît pas dans les réseaux disponibles.

1 Like

Bonjour,

Chez moi la migration ne passe pas.
Voila les log suite à une tentative : https://paste.yunohost.org/raw/zijiyequqo

@Sty_X : comme expliqué dans le disclaimer (et un peu dans la release note), ffsync n’est plus supporté et bloque la migration. Il faut désinstaller l’app.

Mes excuses Aleks, je pensais que ffsync ne fonctionnerait plus après la migration mais pas que l’app bloquait la migration… J’avais mal lu…

Bon en bien j’attendrais que ce soucis soit résolu avant de faire la migration.

1 Like