[RTEX] Jeedom Smart Recovery mode - passage en Buster Jeedom V4

Matériel Jeedom - Hardware La box JEEDOM SMART
,
1

Bonjour à tous, c’est akenad :slight_smile: ,

Aujourd’hui je vais vous présenter un retour d’expérience sur le passage de la Jeedom Smart en Buster/Jeedom V4 par la méthode du Recovery mode (aka Restauration en mode usine) et mise à jour du Kernel.

La méthode à privilégier reste la méthode officielle de Jeedom SAS dite de la « Restauration image », qui se lance depuis l’IHM Jeedom.

La méthode du Recovery mode utilisée dans ce RTEX est l’autre méthode officielle de Jeedom SAS, qui peut être utilisée en cas de problème avec la première méthode.

/!\ ATTENTION : Pour utilisateur avancé, à vos risques et périls.

Ce RTEX a 2 intérêts :

  • il explique comment vérifier si l’image téléchargée n’a pas été corrompue lors du téléchargement.
  • il explique comment mettre à jour le Kernel avant de suivre la méthode du Recovery mode officielle de Jeedom SAS

En effet, la méthode de la « Restauration image » (qui se lance depuis l’IHM Jeedom) met à jour le Kernel, alors que la méthode du Recovery mode ne le fait pas.

La différence se voit dans la page Santé Jeedom , « Version OS » : 3.14.79-94 versus 3.16.85+
(Plus de détails ici : [Présentation] akenad - #10 par akenad)

Nota :

  • Exporter au préalable les sauvegardes de Jeedom.
  • Depuis le 04/01/2020, à partir de Jeedom v4.0.62, la migration buster + kernel est automatisée avec la méthode de la « Restauration image », appelé aussi « mise à jour facile » ou « migration en un clic ») : https://doc.jeedom.com/fr_FR/howto/migrationos.smart
  • Buster sur Smart est vivement recommandé pour les plugin-rfxcom et plugin-zigbee.

Depuis le 24/11/2020 une Smart sur laquelle on procède à un Recovery mode (aka Restauration en mode usine) passe par défaut en Buster/Jeedom V4 (mais sans mettre à jour le kernel) en suivant la documentation officielle de Jeedom SAS ici : https://doc.jeedom.com/fr_FR/installation/smart

Télécharger l’image (Buster/Jeedom V4) « backupJeedom.tar.gz » et le kernel associé (3.16.85+) « kernel.tar.gz » ici : Index of /smart

Nota : Si vous optez pour un téléchargement avec un navigateur, cela semble mieux fonctionner actuellement avec Chrome ou Microsoft Edge Chromium qu’avec Firefox (bien vérifier le hash de l’image, voir plus bas).

Avant d’effectuer le recovery mode nous allons copier le nouveau kernel dans l’eMMC de la Smart. C’est ce kernel qui sera ensuite utilisé lors du recovery mode.

Préparation de la mise à jour du Kernel :

Sur un PC sous windows, décompresser kernel.tar.gz
Copier le dossier /mb_kernel à la racine d’une clé USB

Se connecter en SSH sur la smart en root.

Brancher la clé sur la Smart et monter la clé :

root@jeedom:~# mount /dev/sda1 /mnt

Copier le contenu du dossier /mb_kernel de la clé dans le dossier /mb_kernel de la Smart :

root@jeedom:~# cp -r /mnt/mb_kernel /media/boot/multiboot

Démonter la clé et débrancher la clé :

root@jeedom:~# umount /mnt

Rebrancher la clé sur le PC.
Supprimer le dossier /mb_kernel
Copier l’image backupJeedom.tar.gz.

Vérifier le hash SHA256 de l’image sur la clé,
par exemple avec Windows PowerShell (d’autre outils existent ce n’est pas l’objet de ce sujet).
Ici la clé est sur l’unité F:

info.json
info.json699×279 12.9 KB

CertUtil -hashfile F:\backupJeedom.tar.gz SHA256

powershell-fichier-hash-sha256
powershell-fichier-hash-sha2561020×273 31.1 KB

On constate rapidement visuellement que les hash SHA256 sont identiques.

Nous pouvons maintenant procéder au recovery mode proprement dit.

Opérations à réaliser :

  • éteindre la Smart via le menu de Jeedom
  • retirer tous les périphériques et clés USB
  • laisser le câble réseau branché
  • brancher la clé USB (contenant backupJeedom.tar.gz)
  • brancher un écran sur le port HDMI et un clavier USB
  • débrancher puis rebrancher l’alimentation

Des messages apparaissent sur l’écran :

  • si « BACKUP ARCHIVE FOUND », n’apparaît pas à l’écran, c’est mauvais signe, cela veut dire probablement que le boot sur l’eMMC n’a pas trouvé backupJeedom.tar.gz sur la clé.)
  • si le message « This does not look like a tar archive » n’apparaît pas à l’écran, c’est mauvais signe, cela veut dire probablement que l’image est corrompue suite à un téléchargement incorrect.
    (après téléchargement, bien vérifier le hash de backupJeedom.tar.gz sur la clé)
  • si l’écran devient noir (environ au bout de 10 mn), appuyer sur la barre d’espace pour faire réapparaitre l’affichage.
    Smart-recovery1
    Smart-recovery14032×3024 529 KB

    Smart-recovery2
    Smart-recovery24032×3024 250 KB

Sur la clé USB (et si ce n’est pas le cas c’est mauvais signe) :

  • le fichier backupJeedom.tar.gz est renommé en backupJeedom.tar.gz.installed pour éviter de relancer un autre recovery mode après le reboot.
  • un fichier install.log a été créé, traçant les étapes du recovery mode : « PREPARE CARD, INSTALL BOOT, INSTALL JEEDOM, PREPARE JEEDOM BOOT, INSTALL MULTIBOOT SUPPORT »

La Smart reboot.
Si Debian 8 ou 9 apparaît à l’écran au lieu de Debian 10, c’est mauvais signe, cela veut dire que le recovery n’a pas été réalisé :

Smart-Buster
Smart-Buster4032×3024 335 KB

Jeedom est maintenant accessible par le réseau.
(si ce n’est pas le cas, et qu’après un redémarrage de la Smart, la led est bleue fixe, c’est mauvais signe, cela peut vouloir dire que la partition de boot de l’eMMC à été altérée par le recovery).

Nota : le compte « jeedom » n’existe plus. Pour se connecter à la console ou en SSH, utiliser le compte root.

Il se peut que l’adresse IP de la Smart aie changée. Elle peut être retrouvée :

  • en consultant les baux du serveur DHCP (par défaut la box Internet)
  • sinon un scan sur le réseau avec un outil comme nmap/Zenmap
  • sinon en se connectant sur la console locale de la JeedomSmart (brancher écran HDMI et clavier USB), puis commande :

# sudo ip a

Page Santé Jeedom :
Version OS : Linux Jeedom 3.16.85+ #1 SMP PREEMPT Mon Jul 13 14:40:04 UTC 2020 aarch64 GNU/Linux [10.4]
( => Kernel 3.16.85)
Plus d’infos sur version OS : [Présentation] akenad - #10 par akenad

Concernant la liste des sources de paquets (certains dépôts utilisés lors de l’installation de dépendances de plugins), j’ai conservé debian buster (updates et security) (main, contrib, non-free) et j’ai (à ce stade) désactivé les dépôts « jeedom », "meveric"et « deb-multimedia ».
(A vous de voir si vous estimez en avoir besoin, Jeedom SAS déconseille de désactiver le repo jeedom)

cat /etc/apt/sources.list

Ligne en commentaire (ajout d’un dièse au début de la ligne) :
#deb http://repo.jeedom.com/odroid/ stable main

dans :
ls -ial /etc/apt/sources.list.d

J’ai renommé chaque fichiers en .bak.

Voila j’espère que ce retour d’expérience sera utile aux membres Jeedom.

akenad :slight_smile:

4 « J'aime »
3

Bonjour,

Merci pour le tuto. J’ajouterai de bien penser à faire un backup de Jeedom avant :sweat_smile: pour le restaurer ensuite.

Le smart peut aussi être trouvée en allant sur http://Jeedom.local Il me semble.

4

C’est surtout valider le backup le plus important !
Car si on en prends qu’un et qu’à la restauration on s’apercoit qu’il est corrompu cela n’aura servi à rien.

Donc il faut vraiment valider que le backup est intégre

5

si « BACKUP ARCHIVE FOUND », n’apparaît pas à l’écran, c’est mauvais signe

si le message « This does not look like a tar archive » n’apparaît pas à l’écran, c’est mauvais signe

Si Debian 8 ou 9 apparaît à l’écran au lieu de Debian 10, c’est mauvais signe

après un redémarrage de la Smart, la led est bleue fixe, c’est mauvais signe

ça donne envie de balancer la smart par la fenêtre :nauseated_face:

6

Bonjour @anon55749692,

Ces phrases extraites sont sorties de leur contexte. Mises bout à bout cela peut en effet effrayer. J’ai indiqué aussi les raisons probables de ces événements car ils se sont déjà produits dans la réalité. C’est loin d’être systématique. C’est juste pour prendre conscience que ça peut arriver.
J’ai 2 Smart depuis maintenant 3 ans et j’en suis très satisfait. Pour continuer à profiter de nouveaux plugin ou de nouvelles fonctionnalités ou de révisions majeure de dépendances, le passage du système à Buster devient nécessaire. L’essentiel en fait est d’avoir plusieurs sauvegardes intégres de Jeedom. J’ai déjà expliqué comment restaurer dans certain de mes flash dans : [Présentation] akenad
Ce retour d’expérience se veut juste une aide pour ceux qui souhaitent se lancer dés à présent dans cette nouvelle aventure par la méthode du recovery mode.
Ce RTEX est une avant première en attendant la méthode de la « restauration image », sur le point d’être disponible sur la V4, qui fait tout tout seul.

akenad :slight_smile:

7

Bonjour akenad,

Quand tu n’as qu’une smart à la maison et en production ça donne pas vraiment envie d’intervenir dessus et ça même s’ il y a des petits défauts qui apparaissent à la longue.

Comme beaucoup de personnes j’ai commencé par un raspberry, puis pour la tranquillité j’ai acheté la box dédié, tout en pensant que je serais pas ennuyé par la suite, bin nan!
de jessy il a fallut passer à stretch puis maintenant Buster et je trouve qu’avec la smart c’est plus compliqué.
Je me débrouille mais je suis très très loin du niveau des personnes de ce forum qui jonglent avec tout cela!.. d’où un pincement au cœur quand je trifouille ma p’tite smart.
Mais bon! la domotique c’est cool alors je continue ^^

2 « J'aime »
8

Bonjour à tous,

Effectivement je suis un peu de l’avis de GlloQ .
J’ai une Smart qui tourne bien ,avec maintenant une flopée d’asservissements qui s’enchainent au gré des scénarios.
Tout le montage n’est pas exemplaire ,avec plus de connaissances je suis certain que j’aurais rendu ma p’tite Smart encore plus efficiente , cependant tout fonctionne et se sauvegarde.

Ton tuto me refroidit un chouia , je vais attendre encore quelques temps au cas où une MàJ serait proposée par Jeedom par un simple « clic » , et pourtant j’ai eu mon premier message d’alerte comme quoi mon php était déjà obsolète pour installer un pluggin ; habituellement je mets les mains dans le cambouis.
Sur ce coup , je vais me la jouer « sagesse »
En tout cas merci pour ce tuto qui va souvent me titiller :smiling_imp:

3 « J'aime »
9

Merci pour le tuto et le retour d’expérience … !
Migration sans soucis de mon côté !
Mais en effet, prévoir une « fenêtre de maintenance » familiale :slight_smile:

1 « J'aime »
10

Bonjour @akenad

Il faudrait compléter votre RTEX avec la vérification des fichiers téléchargés avec le fichier SHA256SUMS présent sur le serveur.

En téléchargeant kernel et backupJeedom avec FireFox, je n’arrive pas à les avoir corrects
La vérif des shasum donne systématiquement:
image
Le serveur des images Jeedom est très lent. ~3Mo/s Ca semble perturber FireFox.
Sur 10 téléchargements, pas 1 de bon. Les tailles des fichiers téléchargés sont variables.

En les téléchargeant avec wget en ligne de commande ou avec Chrome, ils sont corrects:
image

Votre chapitre avec CertUtil dans Powershell (sur Mac :thinking:) ne fait que calculer le hash du fichier téléchargé.
Il ne compare pas avec le hash du serveur de Jeedom

Pour résumer, ces 4 commandes en ssh sur la Smart font les téléchargements et la vérif sans PowerShell:

wget https://images.jeedom.com/smart/backupJeedom.tar.gz
wget https://images.jeedom.com/smart/kernel.tar.gz
wget https://images.jeedom.com/smart/SHA256SUMS
shasum -a 256 -c SHA256SUMS

Merci néanmoins pour ce document.

4 « J'aime »
11

Bonjour
C’est quoi les avertissements ?
Le passage en Buster c’est une préco ou ça va devenir indispensable
La procédure n’a pas l’air simple pour des personnes comme moi qui ont joué la sécurité en prenant une smart
Y aura t. Il un modop simplifié accessible à tous comme pour le passage en strech

12

Une mise à jour facilité arrive d’ici quelques semaines. Elle est pour le moment en bêta.

8 « J'aime »
13

Je m’en doutais un peu mais je voulais confirmation
Merci la Team Jeedom :wink:

Sinon, quel est l’objectif de ce changement ?

14

Passage en buster de Debian et mise à jour du kernel pour faire fonctionner certain NUT, clé wifi et surtout le prochain plugin zigbee de Jeedom

3 « J'aime »
15

Et paf ! plantée !

Bonjour,
Ayant reçu la mise à jour v3.3.54, le change log fait état du bouton de mise à jour vers la v4.
En allant plus loin, il est dit que la Jessie n’est pas supporté et qu’il faut passer au moins a la debian stretch. Hors ma smart est sur Jessie et jeedom v3.3.54.
En faisant une recherche, je tombe sur la procédure « d’upgrade facile » vers stretch :
https://forum.jeedom.com/viewtopic.php?f=57&t=44870&sid=a6bb1f7620504d1de0a81beb45add174
Donc pas de probleme, je fait la procédure telle que donnée.
Mais celle ci reste bloquée pendant 4 heures sur le stade 4 :

image
image1336×856 187 KB

En branchant un écran et un clavier, je m’aperçois que celle ci boucle en continue sur le « JEEDOM BOOT MENU v1 » mais n’a plus rien a faire car l’install a déjà eu lieu. Malheureusement mal !
Dans le « JEEDOM BOOT » je n’ai pas le menu « 1 boot to Linux ».
Il y a plusieurs probleme dans votre procédure !
Sur votre site l’image est la dernière en place : Buster avec Jeedom V4.
Hors ma box est elle en Jessie Jeedom V3 !
On parle plus haut de " Avant d’effectuer le recovery mode nous allons copier le nouveau kernel dans l’eMMC de la Smart. C’est ce kernel qui sera ensuite utilisé lors du recovery mode.". Mais est ce que cela à été fait par la procédure normale de passage en stretch donnée plus haut ?
De plus je pense que la procédure de passage en stretch de jeedom ne s’attend pas a tomber sur une version Buster ! Et oui , le nom de l’image est toujours la même !
Et pour finir, la procédure d’upgrade vers stretch doit réappliquer au final la sauvegarde : Bien ! mais je viens d’un Jeedom 3.3.54 et la le fichier backupJeedom.tar.gz c’est une version 4 !
Je suppose qu’il n’est pas possible de faire un restaure sur une V4 d’un fichier de V3 !
Bref, merci de bien vouloir me mettre a dispo le fichier backupJeedom.tar.gz qui corresponds bien a un version de stretch avec un jeedom 3.3.x
A moins qu’il n’y ai une autre solution ?
P.S : La solution : https://doc.jeedom.com/fr_FR/installation/smart
ne fonctionne pas non plus et me fait la même chose que la procédure d’upgrade (boot en bloucle apres la première install).
Je vais posté le log du recovery dans un autre post.

P.S 2 : Ben la box est donc en rade … J’ai plus rien a cette heure ci.
Merci.

1 « J'aime »
16

Voici le log de install.log sur la clef usb :

==== PREPARE CARD ====
65536+0 records in
65536+0 records out
33554432 bytes (34 MB, 32 MiB) copied, 2.88106 s, 11.6 MB/s
/dev/mmcblk0: msdos partitions

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x8b0dab10.

Command (m for help): Created a new DOS disklabel with disk identifier 0x03bd718b.

Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

/dev/mmcblk0: msdos partitions
131072+0 records in
131072+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 5.4645 s, 12.3 MB/s

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): Partition type
   p   primary (0 primary, 0 extended, 4 free)
   e   extended (container for logical partitions)
Select (default p): Partition number (1-4, default 1): First sector (2048-15269887, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (65536-15269887, default 15269887): 
Created a new partition 1 of type 'Linux' and of size 256 MiB.

Command (m for help): Selected partition 1
Partition type (type L to list all types): Changed type of partition 'Linux' to 'W95 FAT32 (LBA)'.

Command (m for help): Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): Partition number (2-4, default 2): First sector (2048-15269887, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (589824-15269887, default 15269887): 
Created a new partition 2 of type 'Linux' and of size 8 MiB.

Command (m for help): Partition type
   p   primary (2 primary, 0 extended, 2 free)
   e   extended (container for logical partitions)
Select (default p): Partition number (3,4, default 3): First sector (2048-15269887, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (606208-15269887, default 15269887): 
Created a new partition 3 of type 'Linux' and of size 8 MiB.

Command (m for help): Partition type
   p   primary (3 primary, 0 extended, 1 free)
   e   extended (container for logical partitions)
Select (default e): 
Selected partition 4
First sector (2048-15269887, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (622592-15269887, default 15269887): 
Created a new partition 4 of type 'Extended' and of size 7 GiB.

Command (m for help): All primary partitions are in use.
Adding logical partition 5
First sector (624640-15269887, default 624640): Last sector, +sectors or +size{K,M,G,T,P} (624640-15269887, default 15269887): 
Created a new partition 5 of type 'Linux' and of size 8 MiB.

Command (m for help): All primary partitions are in use.
Adding logical partition 6
First sector (643072-15269887, default 643072): Last sector, +sectors or +size{K,M,G,T,P} (643072-15269887, default 15269887): 
Created a new partition 6 of type 'Linux' and of size 256 MiB.

Command (m for help): All primary partitions are in use.
Adding logical partition 7
First sector (1169408-15269887, default 1169408): Last sector, +sectors or +size{K,M,G,T,P} (1169408-15269887, default 15269887): 
Created a new partition 7 of type 'Linux' and of size 6.7 GiB.

Command (m for help): The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

/dev/mmcblk0: msdos partitions 1 2 3 4 <5 6 7>
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.090905 s, 11.5 MB/s
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
mkfs.fat 3.0.28 (2015-05-16)
2048+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.103234 s, 10.2 MB/s
mke2fs 1.42.13 (17-May-2015)
Discarding device blocks:    4096/1755136 528384/1755136               done                            
Creating filesystem with 1755136 4k blocks and 438912 inodes
Filesystem UUID: 12378cb1-3dc3-4a73-82b1-530024eeb8af
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

Allocating group tables:  0/54     done                            
Writing inode tables:  0/54     done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information:  0/54     done

/dev/mmcblk0: msdos partitions 1 2 3 4 <5 6 7>
==== INSTALL BOOT ====
442+0 records in
442+0 records out
442 bytes copied, 0.002363 s, 187 kB/s
96+0 records in
96+0 records out
49152 bytes (49 kB, 48 KiB) copied, 0.005009 s, 9.8 MB/s
1184+0 records in
1184+0 records out
606208 bytes (606 kB, 592 KiB) copied, 0.061045 s, 9.9 MB/s
==== INSTALL JEEDOM ====
mkdir: can't create directory '/mnt1': File exists
mkdir: can't create directory '/mnt2': File exists
umount: can't umount /mnt2: Invalid argument
umount: can't umount /mnt1: Invalid argument
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/linux/platform_data/ulpevent.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/linux/platform_data/checksum.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/linux/platform_data/constants.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/linux/platform_data/auth.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/linux/platform_data/command.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/net/nfc/platform_data/ulpevent.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/net/nfc/platform_data/checksum.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/net/nfc/platform_data/constants.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/net/nfc/platform_data/auth.h"
file has vanished: "/mnt1/usr/src/linux-headers-3.14.79+/include/net/nfc/platform_data/command.h"

Number of files: 100,989 (reg: 83,309, dir: 13,265, link: 4,378, dev: 37)
Number of created files: 100,987 (reg: 83,309, dir: 13,263, link: 4,378, dev: 37)
Number of deleted files: 0
Number of regular files transferred: 83,287
Total file size: 3,146,487,784 bytes
Total transferred file size: 2,963,925,667 bytes
Literal data: 2,963,925,667 bytes
Matched data: 0 bytes
File list size: 2,817,850
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2,970,600,044
Total bytes received: 1,669,863

sent 2,970,600,044 bytes  received 1,669,863 bytes  16,840,056.13 bytes/sec
total size is 3,146,487,784  speedup is 1.06
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1183) [sender=3.1.1]
==== INSTALL MULTIBOOT SUPPORT ====
umount: can't umount /mnt2: Invalid argument

Je tiens a préciser que c’est exactement le même que j’ai récupérer en faisant la procédure d’upgrade :
https://forum.jeedom.com/viewtopic.php?f=57&t=44870&sid=a6bb1f7620504d1de0a81beb45add174

Ne vous fier pas au premier post qui dit « /!\ ATTENTION C’EST UNE BETA /! » puisque quelque post plus loin c’est annoncer que ce n’est plus un beta.

Merci pour votre aide !

17

Bonjour @llevet,

la réponse est ici : [Présentation] akenad - #10 par akenad
(mais je conseille plutôt de passer à Buster).

Voir aussi ici :

akenad :slight_smile:

18

Bonjour @akenad

Ok merci ! Je vais donc récupérer l’ancienne image sur le cloud en croisant les doigts !

19

Bon y’a du mieux mais c’est pas encore ça …

La box a repris vie avec l’image :
backupJeedom.tar.gz

Mais le réseau ne fonctionne pas.
Elle prends bien une ip du DHCP mais aucun trafic. Elle ne ping rien et ne peut être pinguée.
Même un ping sur la loopback 127.0.0.1 ne fait rien … J’ai l’impression qu’il y a un probleme sur cette image.
un « arp -na » nous indique que toute les ip sont « incomplete » donc pas une mac adress résolue.

L’image backupJeedomStretch_old.tar.gz fait exactement le même probleme.

Il me reste a tester la Jessie « backupJeedomJessie_OLD.tar.gz »

Mise a jour :
Bon, même probleme avec l’image « backupJeedomJessie_OLD.tar.gz »

Mais y’a un truc bizarre, mon kernel est : Linux Jeedom 3.14.79-94
Celui ci est censé être pour Stretch et non pas pour Jessie !
Donc mon souci de carte réseau qui ne fonctionne pas est surement un probleme de kernel !

PS: J’ai déplacer ma carte emmc sur une autre carte Odroid C2 qui fonctionne bien et le probleme est le même. Donc c’est pas un probleme hardware !

20

Ha oui pour info , y’a toujours les mêmes erreurs dans les logs d’installation :

...
==== INSTALL JEEDOM ====
mkdir: can't create directory '/mnt1': File exists
mkdir: can't create directory '/mnt2': File exists
umount: can't umount /mnt2: Invalid argument
umount: can't umount /mnt1: Invalid argument

Number of files: 81,454 (reg: 67,312, dir: 9,728, link: 4,408, dev: 6)
Number of created files: 81,452 (reg: 67,312, dir: 9,726, link: 4,408, dev: 6)
Number of deleted files: 0
Number of regular files transferred: 67,299
Total file size: 2,226,507,969 bytes
Total transferred file size: 2,219,939,216 bytes
Literal data: 2,219,939,216 bytes
Matched data: 0 bytes
File list size: 2,293,582
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2,225,314,150
Total bytes received: 1,349,320

sent 2,225,314,150 bytes  received 1,349,320 bytes  15,736,137.60 bytes/sec
total size is 2,226,507,969  speedup is 1.00
==== PREPARE JEEDOM BOOT ====
mkdir: can't create directory '/mnt2/media/boot': File exists
umount: can't umount /mnt1: Invalid argument
==== INSTALL MULTIBOOT SUPPORT ====
umount: can't umount /mnt2: Invalid argument
mkdir: can't create directory '/mnt2/multiboot': File exists
21

Bonjour à tous,

J’ai exactement le même soucis, j’ai voulu faire le recovery surtout pour récupérer le plugin Rfxcom.
Une solution?
Merci