J’avais une configuration sur RPI 3B+ + SSD eMMC qui fonctionnait sans problème mais pour laquelle je ne pouvais plus faire de MàJ en raison des plugins incompatibles Debian 10. C’était une 4.4.18 du core.
Je me suis donc mis au passage en v11, en suivant les procédures que j’ai trouvées :
Image clean Bullseye pour 3B+, pas de souci. Le RPI boote, est accessible en SSH, parfait.
install clean jeedom qui se déroule sans accroc a priori
reboot comme indiqué à la fin de l’update, login admin/admin et changement du mot de passe, pas de souci. Pas de mise à jour du core dispo.
upload du backup 4.4.18 d’hier
restore du backup et là … les ennuis commencent. Premier plantage avec une ligne du type « deleting table xxx », impossible d’ouvrir un autre onglet, RPI inaccessible en ssh. Je refais donc toutes les étapes précédentes, plantage à la ligne (là encore de mémoire) « unpacking … », soit encore avant le cas précédent. Je recommence toutes les étapes 1) à 4) et je lance le restore en ligne de commande… ça fonctionne… sauf que :
Au reboot, le RPI est très lent. Il semble que cela fonctionne quelques minutes (mes lametric pilotées par jeedom affichent l’heure en cours, récupèrent quelques infos de capteurs RFXcom, je peux ouvrir un onglet de plugin, etc.) puis se met à être très lent (roue tricolore qui tourne avec l’arrière-plan flou quand on ouvre un onglet), et enfin ne répond plus, y compris plus au ssh.
Il y a les dépendances à refaire, ce qui est consommateur en ressources (pi3b+ c’est un peu juste de nos jours).
Laisser tourner et voir si ça redevient accessible.
Merci pour la réponse, je vais tenter ça. Est-ce qu’il y a des choses que je peux tenter pendant les quelques minutes où j’ai la main au début pour réduire la charge, ou plutôt pour l’étaler ?
Parce qu’en marche courante, la charge CPU est toujours basse, les scénarios quasi-instantanés, les graphes avec 6 mois d’historique de conso avec un point toutes les 20 secondes s’affichent en trois secondes, tout va bien. Ca serait dommage de devoir changer de hard juste pour passer la charge de la restauration…
J’ai la même conf que toi et fait une migration il y 5 jour,
Ce soir suits a une mise a jour du RPI en SSH (paquet firmware etc…)
Je me suis rendu compte que mon swap était occupé a 100% et le RPI devenait inaccessible
Je viens de le remettre le Swap a 1Go… ca semble mieux a voir
Bon alors j’ai tilté sur le sujet du swap, qui en effet est à 100Mo par défaut lors de l’install Bullseye.
Le fait de le passer à 1000 à quand même permis de retrouver une install fonctionnelle, en tout cas suffisamment pour désactiver un certain nombre de plugins, et permettre de retrouver les dépendances.
Malheureusement au bout de quelques heures, cela redevient inaccessible : les pages ne terminent d’abord pas le chargement, puis plus de réponse, ni de possibilité de reprendre la main en ssh. La page santé est toute verte, 96% de dispo sur le disque mSATA.
En parallèle j’ai installé un bullseye standard sur une VM synology, restauré la sauvegarde, tout fonctionne correctement.
Salut je te conseille de réinstaller ton RPI en suivant le tutoriel du forum , plusieurs optimisations notamment le swap sont a faire avant l’installation de jeedom.
Moi tout semble fonctionner depuis.
Je vois que tu a également une VM sur un syno, c’est un vrai plus au niveau maintenance, sauvegarde… si on compare a un raspberry.
Mon raspberry fait tourné une petite installation dans un garage très isolé, ca fait bien le taff mais j’ai toujours peur de planter l’installation, les images de VM aident a etre serein
J’ai renoncé à rétablir Jeedom sur le RPI. Je n’ai pas eu le temps d’investiguer plus.
Si je devais réessayer, je tenterais ce qui est marqué sur ce tuto concernant le journald parce que c’est la seule chose que je vois qui puisse encore faire une différence.
Je ne pense pas comme ça a été dit plus tôt que ce soit un problème de vitesse globale / Perf CPU du RPI 3B+, puisque sur les premières minutes ça fonctionne correctement. Mais comme j’ai finalement tout mon réseau Zigbee+RFXcom fonctionnel sur le Synology, j’en suis resté là. ça me fera un peu de place dans mon coffret élec
Bonsoir, je vais devoir migrer mon RPI 3b+ vers Debian 11 également car impossible de mettre à jour les certificats HTTPS. Avez vous réussi à faire une migration propre ?
