En VM : passage de Debian 9 jeedom 4.0.62 vers Debian 10 jeedom 4.1

Donc voilà, je souhaite passer à la dernière version 4.1
J’ai comme tout le monde le message : pour mettre à jour jeedom en V4.1, il faut passer en Debian 10.

Je suis en VM sur proxmox (NUC Intel)
J’ai donc supprimé la VM (deb9, que j’ai bien sauvegardée)
J’ai recréé à l’identique la VM, avec Deb10. Installation de jeedom (donc V4.1- d’ailleur, en fibre c’est extrèmement rapide :wink: ), téléchargement d’un backup jeedom (en 4.0.62) puis restauration.
Lors du proceesus : message d’erreur :

MySQL] Error code : 42S02 (1146). Table ‹ jeedom.user › doesn’t exist : SELECT id , login , profils , password , options , rights , enable , hash FROM user WHERE id=:id

Bon, forcément, les user ne sont pas présent dans cette nouvelle installation. J’attends, puis au bout de 15mn, toujours rien, donc je m’inquiète, j’ouvre une autre fenêtre, IP de jeedom, rien…

J’ai aussi essayé avec l’iso jeedom, idem.

Avez-vous eu le même problème ? (uniquement des réponse de ceux qui on virtualisé Jeedom sur VM, pas de Smart)

Merci

Hello.

J’ai pas vraiment de solution à proposer puisque ça fonctionne bien systématiquement (même si ça fait longtemps que j’ai pas restauré de 4.0)
As-tu juste forcé les mises à jour avant de faire le backup ?
As-tu utilisé le login admin/admin sur la nouvelle version vide ?
Et même si ça n’a rien à voir avec le souci. Pourquoi virer la vm avant que la suivante ne soit prête ?

1 « J'aime »

Je ne peux pas forcer les MAJ, on n’a plus de possibilité :


le bouton Mettre à jour a disparu.
oui bien sur pour admin/admin : j’accède bien au nouveau jeedom, je le lie au market (d’ailleurs c’est demandé au début), je récupère mon backup.
Pour créer une VM avec la même adresse MAC réseau (pour ne pas tout refaire sur routeur, jpi etc…)
Et aussi pour des questions de ressource sur proxmox, je n’ai pas assez de CPU et espace disque pour doubler ma VM jeedom (sauf à supprimer une VM test en 4.2)

Mais peut-être que je n’attends pas assez longtemps ? mon backup fait 700Mo, il faut peut-être 1h ou plus pour que tout fonctionne ?

Alors tu peux essayer un truc :
Sur la vm propre, directement après la fin de l’installation, en ssh :

  • copier le backup dans le répertoire backup de jeedom (verif des droits www-data)
  • depuis le répertoire install de jeedom : sudo php restore.php

Quand tu restaures, tu embarques tout donc inutile lier au market, c’est écrasé par la suite.

Pour ta vm, si tu es limite au niveau de l’espace disque pour 15go, c’est peut-être le moment de surveiller les soldes.
Niveau ressources tu peux tout à fait réduire les attributions pendant la phase d’installation et remettre correctement après, ça sera juste plus long.
Quand à l’adresse Mac, ça se change aussi à posteriori. Personnellement je fixe les ip dans la vm désormais (/etc/network/interface)

1 « J'aime »

Bonjour,

Dernièrement j’ai appliqué une autre technique pour ne pas devoir refaire la config de ma vm de « prod »: après sauvegardes etc bien sûr j’ai juste détaché son disque et monté un nouveau à la place sur lequel j’ai fait la nouvelle install ainsi pas besoin de refaire le mapping de tout ce qu’il y a autour : dongle usb, Mac etc.
Quand confirmé que tout est OK il suffit de supprimer l’ancien disque qui était juste détaché pour récupérer la place sinon il suffit de faire l’inverse pour repartir sur l’ancienne version.

Concernant ton problème de restaure, on dirait un backup corrompu; p-e dû à l’upload via web.
700mo c’est beaucoup quand même je trouve.
Donc la proposition de @naboleo peut marcher: le copier à la main sur la vm sans passer par jeedom.

3 « J'aime »

Bonjour, et merci pour vos solutions. Le copier direct dans VM, je suis pour mais je ne vous cache pas ne pas être super fort en ligne de commande linux pour faire ceci :

  • copier le backup dans le répertoire backup de jeedom (verif des droits www-data) → droit www-data ?
  • depuis le répertoire install de jeedom : sudo php restore.php → ok donc en root, je me met dans install (/var/www/html/install) puis je fais la commande ?

Ensuite, base corrompu, soit, je vais aussi essayéer une chose avant, supprimer tout l’historique. Mais comment faire ? Car même si je décoche les commandes, l’historique perdure ?

D’ailleurs, elle fait 700Mo aujourd’hui, mais début de semaine dernière, elle faisait 1Go. Le soucis vient de DB_backup.sql (il faisait 8Go, je l’ai fait descendre à 4.5Go)

chown www-data:www-data /var/www/html/backup/*

oui

Il faut purger, c’est encore beaucoup trop gros ! :face_with_head_bandage:
C’est normal que ça prenne du temps à restaurer en plus

1 « J'aime »

Purger, mais comment ? j’ai mis au mini ( commandes suivies 190, toutes avec notion max, mini, moyenne pour archive; aucune timeline, 24H pour archive, Archive par heure, sur 2 ans. C’est quand même pas énorme ? et DB_backup.sql reste à 4.65Go…

je vais mettre à 1 ans. puis si ça me gonfle, décocher les commandes historisés, mettre à 1 jours, et on verra.

Mais bon, comme j’avais beaucoup d’espace, que les sauvegardes sont bien sauvegardés, ben j’avais pas regardé leurs tailles :wink:

La durée c’est un paramètre, tu gardes quoi pour en avoir 190 (j’en ai 20 à tout casser)?
Par exemple la présence 1 mois c’est suffisant (genre plus qu’un départ en vacances)… Température/conso électrique 1 à 3 ans

les températures, ph, salinité etc + températures pièces + luminosité + puissances + conso + index … = 190. J’en avais 532 avant, sur jamais, jamais, jamais ( :wink: ) donc gros ménage et ça ma pris du temps, les états ? j’en garde aucun. sauf les 6 volets et la porte.

Tu compares si les jours sont plus lumineux d’une année à l’autre ?
Idem, les puissances, si tu as la conso, je suis pas convaincu que se soit pertinent
Après chacun fait comme il veux, mais ça me paraît énorme qd même

Énorme, je ne sais pas, ce qui serait bien c’est de savoir combien on peut en mettre. Si il faut 20, 190, 100 = on passe de 500Mo à 1Go, et là on voit que ce n’est pas grave.
Moi, je soupsonnne aussi un problème de corruption, de ligne de la BD qui ne s’efface pas donc cumule. A voir, je vais retraviller ce sujet pour voir si je peux descendre complètement ce DB_backup.

Installe adminer, c’est simple de naviguer dans la base. et de voir les parties les plus importantes


54 historiques finalement

Je suis sur mac

et c’est historyArch qui est énorme

Tu as juste besoin de safari… c’est coté jeedom que ça s’installe (copie pour être plus exacte)

sudo wget https://github.com/vrana/adminer/releases/download/v4.7.8/adminer-4.7.8-mysql.php -O /var/www/html/monadminer.php
sudo chown www-data:www-data /var/www/html/monadminer.php

Après tu as une nouvelle page http://adressejeedom/monadminer.php
Le mot de passe de base est dans la config jeedom

2 « J'aime »

Ah OK, je vais ça
Là je fais une VM et je vais tester les solutions proposées

Au fait comment faire pour envoyer le backup dans répertoire backup ? sachant que mon backup est sur le mac, j’ai trouvé quelques trucs avec scp, mais c’est pas très claire pour moi

Je connais pas trop mac mais https://cyberduck.io/ doit marcher (SFTP)

Bon, j’ai mis le backup dans backup (via jeexplorer), je vais maintenant lancer le restiore en ligne de commande
Il faut être en root pour que cela fonctionne, donc c’est en cours…

Supprimer la table : scenarioElement ...OK
Supprimer la table : scenarioExpression ...OK
Supprimer la table : scenarioSubElement ...OK
Supprimer la table : timeline ...OK
Supprimer la table : update ...OK
Supprimer la table : user ...OK
Supprimer la table : view ...OK
Supprimer la table : viewData ...OK
Supprimer la table : viewZone ...OK
Supprimer la table : widgets ...OK
Restauration de la base de données...

Mais bon on ne sait pas si ça avance, je vais attendre 1H, puis tant pis.