Je viens de procéder à la mise à jour de stretch vers buster, après avoir réussi la mise à jour de jeedom 3.3 vers jeedom 4 il y a un peu plus d’une semaine.
Procédure d’upgrade standard, qui s’est d’ailleurs bien mieux passée que quand je suis arrivé sur etcher. Sauf qu’après l’upgrade et un bon reboot, je vois que mes services ne démarrent pas.
Par exemple apache, il a fallu que je le démarre à la main …
sudo systemctl start apache2
Et du coup quand je me loggue sur la page: SQLSTATE[HY000] [2002] No such file or directory
Faut que je démarre mariadb… mais ça va m’entrainer loin ce truc.
Sauriez vous quels sont les services qui sont censés tourner, et une piste de pourquoi mes services sont dans les choux ? on dirait qu’ils ont été désactivés pendant le dist-upgrade, mais pas relancé à la fin de la procédure. C’est possible ?
Edit: je précise que le RPI démarre bien, j’ai un accès SSH, il m’indique bien tourner sous buster, je tourne sur clé SSD, donc probablement aucune corruption possible, de ce côté là tout va bien.
Stretch ver Buster, non ? Etcher c’est l’outil pour écrire l’image de raspbian sur la carte SD
Pas tellement, dist-upgrade c’est la procédure pas propre de mise à jour… La meilleur méthode, c’est un mise à jour à partir de la SD/SSD (on grave la dernière version de buster), on installe jeedom et on restaure son dernier backup.
Dans le pire des cas, passe les 2 premières étapes avec l’iso Jeedom toute faite.
Apache, php7.x-fpm et mariabd au moins
A noter que la mise à jour via dist-upgrade ne désactive pas les services, il y a eu forcement autre chose
C’est pas trop la question ou le problème mais j’ai déjà expliqué que dans la vie on ne peut pas toujours repartir de zéro. dist-upgrade c’est parfaitement standard dans le monde linux, on ne reset pas son système à chaque changement de version, et heureusement ^^
Si je relance une install jeedom, et que je replace mon backup, je peux peut etre récupérer quelque chose, j’imagine ?
Il y a des procédures de recovery ? je vois rien dans la doc ? un health check, un truc pour dire ce qui est normal, ce qui ne l’est pas.
Un début de réponse: j’ai mariadb-server qui a sauté. La question qu’il va falloir que je me pose … c’est est ce que c’était le seul truc qui a sauté !
La procédure la plus propre est de faire une fresh install buster puis Jeedom puis restauration d’une sauvegarde.
Édit: ne pas oublier d’externaliser la dernière sauvegarde avant de faire la fresh install
J’ai pas souvenir d’avoir lu ton explication à ce sujet, ne pas pouvoir c’est surement pas le mot. Ne pas vouloir c’est un autre débat
La notion de standard est relative : Dans le monde professionnel Linux… Comment dire… C’est banni ce truc …
Quand on bricole c’est acceptable mais ça expose à des risques. Avoir une installation hybride en passant de Jessie => Stretch => Buster, c’est le meilleur moyen de tout foirer
Nada… ça servira à rien du tout.
Jeedom c’est pas fait pour faire du monitoring système… Il sait en gros se soigner lui-même mais pas plus
Ok, bah je ne vous embête pas plus, je vais continuer à réparer mon install.
Si jamais quelqu’un à fait l’upgrade buster et passe dans le coin, qu’il n’hésite pas à me dire, je pense qu’il y a un soucis d’upgrade php-curl également, la version installée par jeedom semble étrange.
J’ai écrit un tuto sur l’upgrade stretch → buster que tu peux retrouver, donc je connais bien le sujet.
J’avais pris un certain nombre d’avis auprès d’autres membres qui s’y connaissaient plutôt bien.
Tu peux retrouver ce tuto dans le forum.
La conclusion est ce que je viens de te dire.
L’upgrade est long, très long, très très long, te fait perdre des services qu’il faut réinstaller, laisse une config bancale et, au final, ne présente aucun avantage voire que des inconvénients.
Si tu veux le faire quand même, libre à toi.
Oh je crois en plus que j’étais tombé sur ton retour d’expérience, et que je me disais que c’était pas si mal, contrairement à d’autres upgrade que j’ai pu faire par le passé.
Je dois tourner la vidéo d’install de jeedom prochainement. Là c’est pas le moment et mon install date de 2016. Jusqu’à présent j’ai toujours mis à jour jeedom sans rien réinstaller, de version en version. Pour l’exercice, mais aussi parce que j’ai énormément d’intégration techniques dans mon raspberry pi, backup, onduleur, monitoring, … sans compter toute la sécurité que j’ai mise en place, et tout refaire, c’est pas du tout dezippe et install.sh, pour moi ce sera des heures de boulot. Donc je le ferai. Mais plus tard, en faisant en même temps une mise à jour matérielle par l’occasion, pour soulager mon RPI2B.
Pour l’instant, je fais au mieux avec ce que j’ai, et il ne me reste plus que zwave à remonter, et ce sera parti.
Pour moi c’est bon, j’ai suivi les diverses indications que j’ai pu trouver sur tes posts, mich0111, ou par d’autres.
Je ne sais pas si mon jeedom est 100% fonctionnel, je vérifie tout en ce moment, mais à part le swap qui a un comportement bizarre, tout le reste à l’air parfait !
Merci !
Concernant le sujet de mettre a niveau ou de repartir sur un système neuf.
Si il y a seulement jeedom et qu’on ne maîtrise pas Linux je pense en effet comme mic0111, c’est plus simple de réinstaller.
Mais sinon il vaut mieux mettre à niveau, Linux est quand-même bien fait.
Et il n’y a pas que les changements de version de la distribution, il est important de faire la mise à jour des services et paquets !
On est quand même sur un système qui est accessible de l’extérieur, et les maj corrigent les failles.
Et ces maj peuvent poser les même problème. . .
Attention, je ne sais pas ce que veut dire ton message, mais ici ce n’est pas linux qui était en vrac, c’est jeedom qui ne repartait pas. Je n’ai eu aucun soucis avec raspberry pi os, l’upgrade c’est superbement bien passé. Je dis superbement, parce que entre jessie et stretch ça a été une autre histoire, si je me rappelle bien, avec les changements de la manière de gérer le réseau et les uuid de partitions.
Mais là, j’étais serein, c’est la partie apache et dependences jeedom qui n’a pas été correctement réalisé.
J’en suis pas à dire qu’il faut dire à tout le monde de faire ainsi. Mais ici, je suis sur le forum communautaire, pas sur la page Facebook, et j’attends effectivement le niveau d’info que j’ai trouvé chez lamor ou mich01111, pas un guide du « tu fais reset et tu réinstalles ». C’est pour moi une solution de dernier recours.
edit: surtout que dans mon cas ce qui bloquait c’était mettre à false une config apache et le redémarrer. Faire réinstaller pour ça, faut vraiment pas pousser ^^ (évidemment, ça nécessite de pouvoir diagnostiquer ce qui ne va pas)
Ben à titre perso tu peux toujours monter la version comme tu le fais là.
Fonctionnellement c’est pas l’idée
tu te traines des repository périmés
tu conserves des libraires anciennes qui servent à rien, sauf à ralentir le système
les versions de python 2/3 et les conflits qui vont avec
ça remet les valeurs par défaut
Bref, c’est vraiment pas propre. Dans le cas, où tu utilises le PI pour autre chose, je comprends bien que c’est plus long…
Mais sachant que Jeedom est quand même pas fait pour cohabiter avec autre chose et à quand même tendance à se croire seul sur le PI, faire de la mutualisation ici, c’est un choix que je ne fais plus. Encore plus quand l’installation du système global (monitoring etc) est critique
On peut polémiquer pendant des années, mais je traine un RPI2B qui n’est certainement pas la plus grosse plateforme pour faire tourner jeedom, et ça tourne très très bien, c’est ultra réactif pour ce que c’est.
Et je n’ai jamais parlé de mutualisation, j’ai dis que dessus j’ai des intégrations. Par exemple, reconfigurer nut, ça ne se fait pas comme ça. Et c’est qu’un exemple. J’ai mes backups externalisés qui sont réglés via scripts. Il faut le remettre en place, le retester quand on repart de zéro.
J’ai la sécurité, avec user dédié et audit que j’ai réalisé. Je réinstalle, je recommence. J’ai la configuration technique: IP fixe, DNS statiques, et autres joyeusetés (swapiness par exemple) que j’ai hardcodé pour supporter toutes les pannes possibles et imaginables que j’ai eu ces dernières années.
Je pense que c’est de la folie que de faire croire qu’on peut prendre la première image raspberry os qui traine, balancer jeedom dessus, et c’est reparti.
Une vraie installation jeedom en production, pour moi, c’est beaucoup plus de réglages que ça quand on est en DIY.
