Bonjour,
J’ai besoin d’avis, je souhaite remplacé mon ancien Hystou par du materiel plus performant et je me demande si je peut sans dégât simplement récupérer mon SSD et l’installer dans le nouveau.
Je tourne sur Debian Strech.
Merci
Nicolas
Bonjour,
Non, ce genre de manipulation n’est pas une bonne idée (cela devrait être une règle : changement de matériel = réinstallation d’OS).
Quoi qu’il arrive, si vous ne faites pas cela, tôt ou tard il y aura des problèmes à faire cela.
=> D’autant, qu’avec une installation, vous allez en profiter pour installer Buster.
Qui dit NUC, dit très certainement des VM, vos VM elles, elles peuvent passer d’une machine à l’autre sans problème.
2 « J'aime »
Ok, merci @Fabrice pour cette précision.
Je vais partir sur une installation propre et faire une restauration de sauvegarde alors.
S’il n’y a que Jeedom sur cette machine, c’est clairement la piste à suivre (nous le faisons très souvent pour des machines de test en restaurant les sauvegardes de la production, c’est éprouvé fonctionnel / rapide / fiable)
Restauration de Jeedom => réinstallation des dépendances => c’est tout.
3 « J'aime »
Je ne suis pas d’accord.
Sur linux, généralement cela ne pose pas de problème, tous les drivers ou autres trucs liés au materiel étant dans le kernel pour 99% de cas.
De plus avec de l’intel nuc, c’est vraiment du matos standard (pas de chip exotiques comme il y aurai sur le hystou) donc pris en charge directement par le kernel dès le boot de debian.
La migration stretch vers buster peut se faire suite à la migration du matos, et cela en quelques commandes (changement sources apt)
Hello,
C’est pas un nuc intel ici justement…
De toute façon, migrer le matos + la distrib, c’est plus long que tout faire d’un coup avec la procédure de backup… Dans les 2 cas, il va falloir se farcir une partie des dépendances, et au final on va trainer des merdouilles sur la migration…
Le seul avantage de migrer c’est que c’est un peu moins risqué que de tout refaire… Mais bon, une restaure ça force à tester le processus en cas de panne réelle c’est pas plus mal
Qualifier l’installation des dépendances des plugins jeedom de « éprouvé, fonctionnel, rapide et fiable » cela m’aura fait rire pour tout l’après midi 
Si il y a bien un truc qui marche pas bien sous jeedom c’est les fameuses dépendances…
Si vous avez confiance en la restauration jeedom
Et dans le cas présent ce n’est pas une simple restauration cas l’OS et le matos seront différents.
Donc restauration puis devoir reinstaller les dépendances jeedom, c’est plus du bricolage pour moi…
Si vous voulez avoir un vrai système de backup, c’est l’ensemble de l’OS contenant jeedom qu’il faut backup (image de VM par exemple).
Car en cas de crash materiel, vous faites quoi avec votre simple zip backup jeedom ? Il faut déjà reinstall tout l’OS, installer jeedom puis finalement restaurer le zip.
C’est pas faux, mais c’est pas uniquement la faute de jeedom… Un shell sans test de code retour à chaque étape ça va pas loin, jeedom ou pas
Sur les plugins officiel c’est bien eux…
Je ne pense pas que les problèmes d’installation des dépendances soient à cause de Jeedom.
C’est justement, à force de croire aux solutions de migrations d’OS, que vous trainez ce genre de truc.
Je restaure très souvent des backups de Jeedom sur des VM ou des Pi différents et, dans le pire des cas, SI l’installation des dépendances n’est pas reprise après un échec du type « une autre installation est en cours », il suffit de la relancer à la mains.
Que cela vous fasse rire c’est bien, que cela signifie que vous avez raison, bah non, je dirais même « justement, il ne faut pas faire comme vous dites ».
Vous avez des tas de sites de connaisseur, qui explique comment migrer une distribution Debian pour conclure qu’il est : plus rapide / fiable / conseillé de ne pas de faire.
Petite expérience du week end dernier : en prévision de la future perte de compatibilité potentielle de Jeedom avec Stretch je me suis livré à cette petite expérience , à savoir migrer ma version de test Raspbian 9 Jeedom V4.0.62 vers une Rasbian Buster 10.7 et Jeedom v4.0.62 selon trois méthodes après sauvegarde de Jeedom et clone du SSD (deux sécurités)
- Méthode 1: mise à jour de la distribution Debian par full upgrade puis récupération de la sauvegarde Jeedom
- Méthode 2 : installation depuis zéro à partir de l’image disque Jeedom , update et upgrade classiques, recréation des utilisateurs Debian
- Méthode 3 : Installation de Buster depuis image Raspbian officielle, update et ugrade classiques, installation de Jeedom v4.0.62 depuis image officielle Jeedom SAS puis restauration de ma sauvegarde Jeedom.
Entre chaque Méthode j’ai restauré mon clone disque initial sur le disque cible .
Conclusions :
- Méthode 1 : longue, très très longue pour les mises à jour et pour finir un problème de configuration Python qui m’empêchait de faire tourner correctement quelques plug ins. J’ai appliqué un tuto de @Fabrice pour résoudre au moins facialement la chose. Comme j’aime les choses carrées et certaines j’ai considéré cette méthode comme non aboutie et peu fiable in fine.
- Méthode 2 : bah la l’opération a durée juste quelques minutes, plus le temps d’étendre les partitions et de restaurer Jeedom , de recréer les users (x2) Debian et de mettre à jour Config.txt et tout a fonctionné sans aucun problème du premier coup.
- Méthode 3 : plutôt longue le temps de réinstaller Buster et de rentrer les paramètres Debian au fil de l’installation (notamment recréation des users). Puis ensuite mise à jour du Config.txt, installation de Jeedom assez rapide et enfin restauration Jeedom . Tout a fonctionné dans la foulée.
Comme je suis un peu maso sur les bords et beaucoup au milieu j’ai répété la manip sur un Intel NUC 8i5BEH et disque M2 SATA…
Pour la faire courte mêmes conclusions que sur le RPI.
Morale de mon histoire. NE PAS FAIRE DE MIGRATION PAR UPDATE DE DEBIAN DEPUIS UNE ANCIENNE VERSION sauf à maîtriser complètement LINUX (et encore !).
Y préférer soit une installation neuve avec restauration Jeedom (ma préférée car complètement reproductible et flexible) soit une installation depuis les images toutes faites de Jeedom (très bien bien mais pas ma préférée car dépend de la politique de Jeedom à poursuivre la création de ces images concernant les configs DIY càd non vendues par Jeedom SAS)
3 « J'aime »
Pour la méthode 1, pourquoi restaurer un backup de jeedom après la maj Debian ?
Perso, mon install jeedom a initialement faite sur jessie dans une vm esxi. Au fil des années : full upgrade de debian, migration de la vm esxi vers proxmox (changement materiel + d’hyperviseur, sans aucune reinstall de vm !) puis encore full upgrade debian.
Jamais je n’ai eu a restaurer de backup jeedom
Les maj Debian sont très robustes.
Et bien entendu, bcp plus fiable que les montées de version jeedom : il n’y a qu’a voir tout les sujets sur les problèmes de maj jeedom, deamon de plugins qui veulent plus demarrer, version php/python pas compatible et j’en passe…
Et avec des vm, c’est encore moins une excuse de ne pas passer par une nouvelle installation !
L’ancien jeedom tourne, pendant ce temps on crée tranquillement une nouvelle vm, avec un jeedom propre.
Backup copié de l’ancienne vers la nouvelle vm, suivi d’une restauration toute bête.
Changement de ip et passthrough usb…
En gros, on doit pas avoir moins de 10 minutes d’interruption de service tout en gardant la possibilité de revenir complètement en arrière si par un hasard peu probable ça coince sur la nouvelle installation
1 « J'aime »
Si vous n’avez rien a configurer sur l’OS, pourquoi pas.
Avec la VM c’est aussi très facile et rapide de faire un snapshot complet => restaure complète OS+jeedom si la maj se passe mal
Quel genre de modif qui ne serait pas de nouveau réalisable sur la nouvelle vm ?
Justement c’est l’occasion, ça doit se limiter à des modifications mineures (de toute façon jeedom se croit un peu tout seul en son château). Si besoin d’un truc un peu touchy (proxy par exemple) une vm à part est bien plus efficace… Très franchement autant je conviens que la gestion des dépendances est pas optimale mais dans ces conditions c’est tout faire pour que ça coince encore plus
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.