My YunoHost server
Hardware: Olimex lime 2 with vpn
YunoHost version: 3.8.6 a 4.0
I have access to my server : tout
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
La migration devrait d’abord contrôler la présence du mot de passe root ou même obliger à le réentrer car en cas de perte de problème…
Ma migration qui n’est pas sur une installation super particulière, a raté au niveau de l’upgrade des package. Donc relativement tôt dans le processus.
J’ai du coup engagé l’upgrade apt manuellement. Je n’ai bizarrement pas eu de soucis du coup, sauf à la toute fin avec sysfs.
Toutes les connexions ont été rompues évidemment. Sauf le ssh. Mais comme je n’ai pas continué directement, j’ai perdu la connexion. Fatalement du au changement des fichier de config openssh le root n’est plus accepté donc il a fallu que j aille sur l appareil lui même pour réautoriser l accès root en ssh. Plusieurs connexion vpn les mêmes se sont superposées aussi ce qui veut dire qu’un arrêt total du vpn durant une migration serait une bonne idée car sinon perte de connectivité par un trop plein de route les mêmes ( sauf en ce qui concerne l’interface)…
Heureusement que j’ai eu la présence d’esprit d’à jaque fois faire un .back pour chaque fichier de configuration que apt voulait changer. Il faudrait inclure d’office une fonctionnalité comme celle là dans un script de migration. Ne pas compter seulement sur le fait que l’utilisateur ait fait un backup. Un backup peut être partiel, incomplet pour x dizaines de raisons, etc.
Selon moi le script de migration devrait être en plusieurs partie et devrait pouvoir être relancé par étape.
ici le log de d’échec de départ.
https://paste.yunohost.org/raw/buhewizana
ici le dernier problème apt
After this operation, 0 B of additional disk space will be used.
Setting up sysfsutils (2.1.0+repack-5) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Job for sysfsutils.service failed because the control process exited with error code.
See "systemctl status sysfsutils.service" and "journalctl -xe" for details.
invoke-rc.d: initscript sysfsutils, action "restart" failed.
● sysfsutils.service - LSB: Set sysfs variables from /etc/sysfs.conf
Loaded: loaded (/etc/init.d/sysfsutils; generated)
Active: failed (Result: exit-code) since Sat 2020-08-01 15:35:24 UTC; 164ms ago
Docs: man:systemd-sysv-generator(8)
Process: 7972 ExecStart=/etc/init.d/sysfsutils start (code=exited, status=1/FAILURE)
Aug 01 15:35:23 dev.consulting.net systemd[1]: Starting LSB: Set sysfs variables from /etc/sysfs.conf...
Aug 01 15:35:24 dev.consulting.net sysfsutils[7972]: Setting sysfs variables.../etc/init.d/sysfsutils: 50: echo: echo: I/O error
Aug 01 15:35:24 dev.consulting.net systemd[1]: sysfsutils.service: Control process exited, code=exited, status=1/FAILURE
Aug 01 15:35:24 dev.consulting.net systemd[1]: sysfsutils.service: Failed with result 'exit-code'.
Aug 01 15:35:24 dev.consulting.net systemd[1]: Failed to start LSB: Set sysfs variables from /etc/sysfs.conf.
dpkg: error processing package sysfsutils (--configure):
installed sysfsutils package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
sysfsutils
E: Sub-process /usr/bin/dpkg returned an error code (1)
Sachant que le fichier de config est
#
# /etc/sysfs.conf - Configuration file for setting sysfs attributes.
#
# The sysfs mount directory is automatically prepended to the attribute paths.
#
# Syntax:
# attribute = value
# mode attribute = 0600 # (any valid argument for chmod)
# owner attribute = root:wheel # (any valid argument for chown)
#
# Examples:
#
# Always use the powersave CPU frequency governor
# devices/system/cpu/cpu0/cpufreq/scaling_governor = powersave
#
# Use userspace CPU frequency governor and set initial speed
# devices/system/cpu/cpu0/cpufreq/scaling_governor = userspace
# devices/system/cpu/cpu0/cpufreq/scaling_setspeed = 600000
#
# Set permissions of suspend control file
# mode power/state = 0660
# owner power/state = root:power
block/mmcblk0/queue/scheduler = noop
#block/sda/queue/scheduler = cfq
EDIT:
visiblement noop n’a plus l’air d’être accepté comme scheduler I/O mais je n’ai trouvé aucune référence concernant ce changement et il semble que ce soit même cantonné à debian puisque ubuntu reprend encore les référence noop (noop qui n’est pas équivalent à none pour info comme signaler ici
Je l’ai temporairement remplacé par none mais si quelqu’un sait par quoi remplacé noop dans le cadre d’une carte SD pour améliorer la longévité de cette carte SD ce serait sympa?
EDIT2:
Dans la seconde partie de la migration
Ca serait bien que ne fut-ce que sur l’interface web, on est une partie réservée aux fichiers de référence qui étaient censés être modifiés et qui ne l’ont donc pas été.
The configuration file '/etc/nslcd.conf' has been manually modified and will not be updated
Configuration updated for 'yunohost'
The configuration file '/etc/resolv.dnsmasq.conf' has been manually modified and will not be updated
The configuration file '/etc/fail2ban/jail.conf' has been manually modified and will not be updated
The configuration file '/etc/fail2ban/jail.d/yunohost-jails.conf' has been manually modified and will not be updated
Configuration updated for 'dovecot'
Configuration updated for 'nsswitch'
The configuration file '/etc/ldap/schema/mailserver.schema' has been manually modified and will not be updated
The configuration file '/etc/ldap/schema/sudo.schema' has been manually modified and will not be updated
The configuration file '/etc/ssh/sshd_config' has been manually modified and will not be updated
Could not run script: /usr/share/yunohost/hooks/conf_regen/43-dnsmasq
Dans ce cas-ci il y a quand même une certaine quantité de fichiers liés à la sécurité, et parce qu’ils ont été modifiés manuellement, je ne peux donc pas savoir ce que yunohost avait prévu comme template de ces fichiers. Or si j’avais directement accès à cette information dans ma partie admin, je pourrais comparer et les modifier à dessin ou en tout cas évaluer la nécessité de les faire évoluer ou non.
Visiblement il y a aussi un problème au niveau de la migration de la db postgres (dont je n’ai pas encore les connaissance de savoir où elle se trouve dans la hiérarchie de l’infra yunohost et donc son utilité).
Migration 0016_php70_to_php73_pools completed
Running migration 0017_postgresql_9p6_to_11...
grep: write error: Broken pipe
grep: write error: Broken pipe
Cluster is not running.
Error: could not stop server, aborting
Migration 0017_postgresql_9p6_to_11 did not complete, aborting. Error: Command 'pg_dropcluster --stop 11 main' returned non-zero exit status 1
ici pour ce qui est du log qui n’apporte que peu de réponse
Est-ce dû au fait que j’aie dû faire un apt dist-upgrade manuellement et qu’il a donc upgrade la db via apt et casser tout le processus, sans plus d’informations je ne saurais dire.
pas encore de solution pour la migration de psotgres, c’est la seule qui est en mode pending apparemment.
root@dev:/usr/lib/moulinette/yunohost/data_migrations# yunohost tools migrations migrate
Info: Running migration 0017_postgresql_9p6_to_11...
grep: write error: Broken pipe
grep: write error: Broken pipe
Cluster is not running.
Error: could not stop server, aborting
Error: Migration 0017_postgresql_9p6_to_11 did not complete, aborting. Error: Command 'pg_dropcluster --stop 11 main' returned non-zero exit status 1
Info: The operation 'Run migrations' could not be completed. Please share the full log of this operation using the command 'yunohost log display 20200802-011903-tools_migrations_migrate_forward --share' to get help
Je mettrai à jour ce thread au fur et à mesure du debug