Oui, tout à fait… J’ai la version à 4 Go, ce qui devrait suffire largement…
Bon ben échec !
DB cassée visiblement…
Et quand je tape sur l’@IP (just for fun…)
Au moins le serveur Apache est opérationnel lui…
Et bien sûr, après presque 2h d’install c’est vers la fin que ça foire…
Pas grave, shoot again…
Bonjour
Pour cette version de l’os il faut le sceupt d’installation alpha et non la stable
Ah, ok, merci pour l’info… Bon, je réessayerai avec l’apha !
1 « J'aime »
Bonjour,
Effectivement, avec la v4.4.0 Alpha, c’est beaucoup mieux !
Vu la charge (à vide), je crois qu’il y a pas mal de potentiel derrière avec ce RPi5…
Par contre, et c’est peut-être normal, mais il m’est impossible de charger une sauvegarde existante (faite en v4.3.20).
J’ai ce message d’erreur qui apparaît :
Et je reste bloqué ici :
Du coup, si mes scénarios et plugins sont bien activés (vu tous les messages d’erreur divers et variés reçus), par contre je ne peux pas aller plus loin.
Et d’ailleurs, si je me souviens bien, j’avais eu le même problème en tentant de la même façon de restaurer une sauvegarde sur un système plus ‹ standard › sur RPi4B avec un Debian v11 Bulleyes tout neuf, mais je n’avais pas été plus loin non plus…
J’ai loupé un truc ?
Bonjour
Oui la 4.3 n’est pas compatible debian 12 donc forcément la restoration de backup ne marche pas
Bonjour,
Idée : installer un Jeedom 4.3.20 sur un Debian 11 ou 10
Faire une sauvegarde
Faire la migration vers Jeedom 4.4
Faire une sauvegarde
Restaurer cette sauvegarde sur le Jeedom 4.4 en Debian 12
Ok, merci.
Je comprend l’idée de manœuvre que je vais donc tester : upgrader Jeedom de la 4.3.20 > 4.4.0 puis reconstruire un système à base de Bookworm + la 4.4.0.
Espérons que ça marche, parce que sinon je ne pense pas que ce soit intéressant de sauter le pas (même à terme) s’il faut tout refaire à la main derrière…
Ce que je vous propose doit fonctionner, c’est même certains !
Oui…Sauf que…
Voilà le dilemme :
Sur les RPi5, visiblement on ne peut installer que la version 12 de Debian, Bookworm. Mes tentatives d’installation de Debian 10 ou 11 jusqu’à présent ne fonctionnent pas (pas de boot).
Ceci dit rien d’étonnant, c’est bien ce qui avait été annoncé, mais je confirme donc le fait pour ceux qui en doutait.
Du coup, je me retrouve, au mieux, avec un RPI5 + Bookworm + une installation vierge de jeedom en v4.4.0 Alpha, mais sans possibilité d’uploader une sauvegarde faite sur mon système opérationnel (RPi4B + Debian v10 Buster + Jeedom 4.3.20).
Comme je ne souhaite (vraiment pas…) toucher à mon Jeedom opérationnel pour l’upgrader en v4.4.0 Alpha et faire une sauvegarde, je vais devoir déstocker mon vieux RPi3B+ du placard pour refaire une installation complète avec Debian 10 + Jeeedom 4.3.20 et lui envoyer la restauration effectuée. A l’issue, je le passerai en V4.4.0 Alpha, sauvegarde, puis restauration sur le RPi5 en v12.
Ça paraît jouable ?
Creer une vm provisoire sur pc ou mac sera plus simple et rapide a mes yeux !
Oui, bien sûr… Pourquoi faut-il que je me complique toujours la vie moi… 
Bonjour,
Au résultat pour cette journée, j’ai donc installé sur mon vieux RPi3B+ (oui, je sais, mais j’avais la flemme de monter une vm…) Debian v11 Bulleyes + Jeedom legacy en v4.3.20. A partir de là, j’ai restauré une sauvegarde récente, pas de problèmes.
Ensuite, j’ai passé le core en v4.4.0 Alpha. A l’issue de l’upgrade, tout est OK (à part 2 plugins à remettre à jour, mais rien de bloquant).
Je lance une sauvegarde, puis j’ai tenté la restauration de celle-ci sur le RPi5 (Debian v12 / jeedom v4.4.0 Alpha).
Et là, ben ça bloque toujours.
Tout semble pourtant se dérouler nominalement, mais là ça fait 1h que ça tourne, mais ça n’avance plus. De temps en temps je reçois bien un signe de vie via des erreurs qui remontent (par SMS), du type ‹ La tache plugin::cron n’arrive pas à finir à cause du plugin : wazetime nous vous conseillons de désactiver le plugin et de contacter l’auteur ›. Du coup, je laisse tourner pour l’instant, mais je pense que si les tâches programmées dans le cron restent actives (d’où ces alertes), le système lui-même ne réagit plus.
J’ai tenté un reboot et une restauration en mode rescue (c’est la copie d’écran) mais ça fini par bloquer au même endroit.
Donc pour l’instant c’est pas concluant…
Ah oui, je note encore cette erreur aussi :
Pourtant il dit bien qu’il a restoré la db c’est bizarre surtout sue je reproduis pas mais j’ai pas de rpi5 non plus.
Bonjour,
Qu’est ce qui se passe si tu restaures la sauvegarde du RPi3B+ en 4.4 sur lui-même ?
akenad 
Pas grand chose !
Effectivement, le backup semble un peu vérolé, le RPi3 est bloqué depuis un bon bout de temps sur cette ligne…
Bon, j’attends encore un peu (un RPI3 n’est pas un RPI4 ni un RPI5…) et je relance la procédure complète…
Bonjour,
J’ai retenté une sauvegarde puis une restauration de cette image à partir du/vers le RPi3B+ (Debian 11.8/Jeedom v4.4.0 Alpha) ce matin, et c’est bon. Ça a pris du temps (pas loin de 7’ quand même), mais c’est passé… Donc le fichier de backup utilisé est bien valide.
Du coup, j’ai refait une installation complète sur le RPi5 : Debian 12 + l’update/upgrade qui va avec, puis Jeedom en v4.4.0 (directement en lignes de commande : wget https://raw.githubusercontent.com/jeedom/core/alpha/install/install.sh, puis chmod +x install.sh, puis sudo ./install.sh -v alpha).
Résultat : tout à l’air OK.
Puis j’ai tenté de passer à la dernière étape en restaurant la sauvegarde validée sur ce système tout frais (à signaler la taille de 125Mo de celle-ci, je ne sais pas si cela a une influence…).
Pendant le processus (à la ligne ‹ Restoring Database from backup ›), ce message d’erreur est apparu :
Et depuis je reste bloqué ici, comme hier :
Toujours avec les messages d’alerte périodiques en provenance des plugins qui ont programmés des tâches dans le cron, mais sans possibilité de les mener à bien.
Si je tente de charger une page quelconque (design, etc…), je tombe sur une page blanche.
Ce second essai débouchant sur les mêmes résultats n’est donc toujours pas concluant, mais peut-être que j’ai fait une erreur quelque part dans la procédure ?
Bonjour,
Il faudrait lancer la restoration en ligne de commande pour voir le soucis, je pense c’est spécifique a debian 12 pi5 mais je n’ai malheureusement pas de pi 5 (et je n’ai pas prévu d’en avoir) donc ca va prendre du temps de trouver le probleme.
Ok, pas de soucis, je vais essayer en brut… En tout cas si on peut faire avancer le schmilblik avec mon exemplaire de RPI5…
