Forum Communauté Jeedom

Bonjour à tous,

Nous lançons la beta de la migration Facile des Smart vers Stretch.

/!\ ATTENTION C'EST UNE BETA /!\

pour accéder a cette nouvelle page il vous faut mettre dans votre url : [Adresse de votre Jeedom]/index.php?v=d&p=migrate

Sous un Jeedom sous 3.3.10 ou sup.

puis suivre les instructions. voila ce que fait la migration Facile :

- Backup de votre Jeedom
- Enregistrement du Backup sur la clé USB
- Téléchargement de l'image Stretch sur la Clé USB
- Installation de l'image
- Redémarrage de la Jeedom
- Demande si installation du backup.

la seul chose a ne jamais faire pendant le restore c'est de débrancher la Jeedom. après le mieux étant de laisser la page de restauration toujours visible sur votre ordinateur.

Merci pour vos retours.

Bonjour Loic, je serai intéressé en stable.
Quand tu parles de clé USB, tu veux dire qu'avant de lancer la migration il faut mettre une clé USB vierge sur l'un des 4 ports de la smart ?

Envoyé de mon Samsung Note 8 en utilisant Tapatalk

Bonjour,

Oui c'est ce qu'il faut faire. quand on lance la page migration elle le demande (tout est Wizardé ^^)

n'ayant d'une SMART de prod, je vais aussi attendre la stable, merci pour cette info

Bonjour,

Si ça "brique", il y a une prise en charge SAV ?

BC

Il y a des retours positifs de cette méthode de maj ?

benchagot a écrit : ↑
23 avr. 2019, 15:31
Bonjour,

Si ça "brique", il y a une prise en charge SAV ?

BC

Oui pas de problème.

Mais ça ne devrait pas si vous suivez bien les instructions et surtout ne pas débrancher la smart pendant toute la procédure ! Même si ça a l’air bloqué !

Merci

Bonjour,
Après avoir trouvé une clé de taille correcte, et ce message:
votre clé USB à un espace trop petit (7627.078125 Mo) il faut un minimum de 7900 Mo. <br />Merci

J'ai ce message: Merci de formaté correctement votre clé USB

Qu'appelez-vous correctement? J'ai essayé les 3 formats dispo avec Windows FAT32, NTFS et exFAT sans succés.

'Jour,

Vu que l'OS est du linux il faut pas un formatage sous linux ?

Selon les sources de la classe migrate, le formatage correct est VFAT/FAT32.

La commande df me dit que:
La clé trop petite utilise /dev/sda1 ( montage dans /media/usb0 )
La clé qui produit l'erreur de formatage utilise /dev/sda ( montage dans /media/usb0 )

Log http.error:

Code : Tout sélectionner

mkdir: cannot create directory '/media/migrate': File exists
mkdir: cannot create directory '/media/migrate/Backup': File exists

La valeur de freeSpaceUsb()/1024 est de 15391.98046875

Je modifie usbTry pour aller plus loin en utilisant /dev/sda?
Je réduis la taille imposée de 7900 à 7600 pour pouvoir utiliser ma clé de 8Go?

J'ai finalement trouvé une 3ème clé USB qui utilise /dev/sda1. La migration continue.

JE suis bien tenté de le faire mais je vais d'abord attendre de ne plus avoir besoins du chauffage....

Si j'ai bien compris il faut une clé usb de 8GO minimum formatée en fat32 c'est bien ca ?

Déjà 4h que la migration tourne.
Le processus est bloqué à l'étape 5 à 30 %

Le log update avec une erreur fatale PHP:

Code : Tout sélectionner

[START UPDATE]
****Update jeedom from 3.1.7 (2019-04-25 12:51:47)****
Parameters : Array
(
[preUpdate] => 0
[backup::before] => 0
[plugins] => 0
[core] => 1
[force] => 0
[update::reapply] =>
)
Send begin of update event...OK
Check rights...OK
Disable all task
OK
Disable all scenario OK
Clean temporary file (tmp)...OK
Download url : https://github.com/jeedom/core/archive/stable.zip
Download in progress...--2019-04-25 10:51:49--  https://github.com/jeedom/core/archive/stable.zip
Resolving github.com (github.com)... 140.82.118.4, 140.82.118.3
Connecting to github.com (github.com)|140.82.118.4|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/jeedom/core/zip/stable [following]
--2019-04-25 10:51:49--  https://codeload.github.com/jeedom/core/zip/stable
Resolving codeload.github.com (codeload.github.com)... 192.30.253.121, 192.30.253.120
Connecting to codeload.github.com (codeload.github.com)|192.30.253.121|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: '/tmp/jeedom/install/jeedom_update.zip'
0K ...
535K
3072K ..
352K
6144K .
.  271K
9216K ..
.  319K
12288K .......
. .......
. .....
... ...
..... ...
..... .
.......  413K
15360K ......
.. .....
... ......
.. ......
.. ........
........  500K
18432K ...
..... .....
... ......
.. ........
........
........  552K
21504K ..
...... ....
.... ....
.... ......
.. .......
. ........  549K
24576K ........ .
....... .
....... ..
...... .....
... .......
.  556K
27648K ........
.......
. ......
.. .......
. .......            484K=71s
2019-04-25 10:53:01 (425 KB/s) - '/tmp/jeedom/install/jeedom_update.zip' saved [30920953]
OK
Cleaning folder...OK
Create temporary folder...OK
Unzip in progress...
OK
Moving file...
OK
Remove temporary file...
OK
Update system into : 3.1.8...
W: The repository 'http://repo.jeedom.com/odroid dists/stable/main/binary-arm64/ Release' is not signed.
W: No Hash entry in Release file /var/lib/apt/lists/partial/repo.jeedom.com_odroid_dists_stable_main_binary-arm64_Release
W: Invalid 'Date' entry in Release file /var/lib/apt/lists/partial/repo.jeedom.com_odroid_dists_stable_main_binary-arm64_Release
W: Conflicting distribution: http://repo.jeedom.com/odroid dists/stable/main/binary-arm64/ Release (expected dists/stable/main/binary-arm64/ but got )
Update APT sources
OK
Disable constraint...OK
Update database into : 3.2.1...OK
Enable constraint...OK
Update system into : 3.2.1...OK
Disable constraint...OK
Update database into : 3.2.2...OK
Enable constraint...OK
Update system into : 3.2.4...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:
OK
Update system into : 3.2.5...
OK
Update system into : 3.2.6...OK
Update system into : 3.2.12...OK
Update system into : 3.2.16...--2019-04-25 10:53:24--  http://ftp.debian.org/debian/pool/main/a/at/at_3.1.16-1_arm64.deb
Resolving ftp.debian.org (ftp.debian.org)... 2001:67c:2564:a119::148:12, 130.89.148.12
Connecting to ftp.debian.org (ftp.debian.org)|2001:67c:2564:a119::148:12|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-04-25 10:53:24 ERROR 404: Not Found.
dpkg-deb: error: '/tmp/at.deb' is not a debian format archive
dpkg: error processing archive /tmp/at.deb (--install):
subprocess dpkg-deb --control returned error exit status 2
Errors were encountered while processing:
/tmp/at.deb
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:
Add atOK
Disable constraint...OK
Update database into : 3.3.0...OK
Enable constraint...OK
Update system into : 3.3.0...
debconf: unable to initialize frontend: Dialog
debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
dpkg-preconfigure: unable to re-open stdin:
OK
Disable constraint...OK
Update database into : 3.3.1...OK
Enable constraint...OK
Disable constraint...OK
Update database into : 3.3.2...OK
Enable constraint...OK
Disable constraint...OK
Update database into : 3.3.3...OK
Enable constraint...OK
Disable constraint...OK
Update database into : 3.3.9...OK
Enable constraint...OK
Update system into : 3.3.9...Add atOK
Update system into : 3.3.10...
OK
Update system into : 3.3.11...Warning: apt-key output should not be parsed (stdout is not a terminal)
Update Jeedom repositoryOK
Update system into : 3.3.12...
cp: cannot stat '/var/www/html/install/update/../../core/img/plan_*': No such file or directory
OK
Update system into : 3.3.14...OK
Check jeedom consistency...[START CONSISTENCY]
[END CONSISTENCY]
OK
Check update...PHP Fatal error:  Uncaught Error: Call to undefined method utils::attrChanged() in /var/www/html/core/class/update.class.php:608
Stack trace:
#0 /var/www/html/core/class/update.class.php(54): update->setType('core')
#1 /var/www/html/install/update.php(326): update::checkAllUpdate('core', false)
#2 {main}
thrown in /var/www/html/core/class/update.class.php on line 608

Edit: 15h30
Essai non concluant. J'abandonne.
De plus, le répertoire Backup de la clé USB ne contient même pas un backup fait ce matin au lancement de la migration. C'est celui du 23 avril à 19h38 en 3.3.21 alors que ce matin j'étais en 3.3.22 et que le backup de cette nuit est plus récent.

Le système est en stretch. ( 9.4 dans /etc/debian_version )
Mise à jour Jeedom de 3.3.18 en 3.3.22
Reinstall du dernier backup en ma possession.
Reinstall des dépendances des plugins HS.

Merci pour vos retours je corrige c'est deux points. dans nos box de test nous n'avons pas de backup donc pas vu ce souci.

pour le 30% sur la 5eme étape c'est du a la Maj de Jeedom qui ne passe pas correctement (pas de END) une nouvelle image sur nos serveur en stretch sera deployer avec la dernière Maj de Jeedom (pour éviter de refaire des Maj a la page de Migration).

xavax a écrit : ↑
25 avr. 2019, 11:50
JE suis bien tenté de le faire mais je vais d'abord attendre de ne plus avoir besoins du chauffage....

Si j'ai bien compris il faut une clé usb de 8GO minimum formatée en fat32 c'est bien ca ?

Oui, il faut une clé USB en FAT32 avec au moins 8Go libre. Jeedom ne la formate pas.
Et dans l'état actuel de la migration, il est urgent d'attendre.

rocket13011 a écrit : ↑
25 avr. 2019, 17:18
Merci pour vos retours je corrige c'est deux points. dans nos box de test nous n'avons pas de backup donc pas vu ce souci.

pour le 30% sur la 5eme étape c'est du a la Maj de Jeedom qui ne passe pas correctement (pas de END) une nouvelle image sur nos serveur en stretch sera deployer avec la dernière Maj de Jeedom (pour éviter de refaire des Maj a la page de Migration).

Bonjour rocket13011,

1- Est-ce vraiment nécessaire de faire les mises à jour Jeedom puisque la récupération du backup écrase tout (js, css, php et bdd)?
Je n'ai pas eu la question si je voulais récupérer le backup.
Jeedom 3.1.3 est installé avec stretch. Donc beaucoup de mise à jour à faire.
Les plugins fournis(openzwave, weather, widget, virtual, script, mail) datent de septembre 2017.

2- L'upgrade de la bdd semble incomplet.
Adminer signale 2 erreurs sur la bdd jeedom:
- Cannot load from mysql.proc. The table is probably corrupted
- Cannot proceed because system tables used by Event Scheduler were found damaged at server start
Comment corriger ces erreurs dues à l'upgrade de version de Mysql/MariaDb?

3- Stretch comme Jessie sont installés avec uniquement les locales C et en_US.
Il manque au moins fr_FR.utf8 pour pouvoir avoir les noms des jours et des mois en francais en php.

4- Je vous ai fait un PR pour corriger les plus grosses fautes de la procédure de migration.
Il y a aussi un autre PR en suspens depuis février sur le plugin livebox.

Jp

1 - Oui car pas la class Migrate dans l'ancienne version

(mais ça va changer une nouvelle image est en cours )

2 - la prochaine image corrige cela.

3 - je regarde.

4 - j'ai accepté

Ayant déjà migré sans soucis sur Stretch (via la méthode manuelle) il y a quelques semaines, j'aimerais savoir si je devrais appliquer une nouvelle fois cette migration étant donné que d'après le message précédent, l'image va être modifiée ?

Bonjour,

Tout dépendra du contenu de la nouvelle image.
Si c'est une stretch 9.4 comme l'image précédente, ce sera inutile.

jp

Bonjour,
Personnellement sur ma smart en souffrance, j'ai tenté une migration. Clef de 32Go formaté en FAT32.
A l'étape 2 je suis resté bloqué à 70% sur "vérification du backup". Depuis que je reprend ou non la procédure (popup proposée à chaque fois), il me dit que le backup na pas pu être copié (80%). Même si je reformate la clef. Et je peux pas aller plus loin.

Tu peux aller dans configuration / OS_DB / puis Systeme .
la si tu peux mettre cette ligne :

apt-get install -y rsync

et me donner ce qu'il te donne, j'ai peur que Debian a viré le depot Jessie ARM64 pour rsync.

Forum Communauté Jeedom

Migration des smart stretch

Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch

Re: Migration des smart stretch