Tuto HC2 Hc2 Usb Recovery Tweaks

**Lazer** · le 24 octobre 2014

Les manipulations présentées dans ce sujet de discussion sont destinés à des utilisateurs avancés disposant des compétences nécessaires, et je décline tout responsabilité en cas de fausse manipulation rendant votre clé USB Recovery inopérante, voire même votre Home Center 2.

Introduction

Voir : Sauvegarde, Restauration, Et Recovery Sur Home Center 2

Clonage de la clé USB de Recovery

Présentation de la clé

La clé USB fournie avec la box Fibaro Home Center 2 est un élément critique, car sans elle la box ne peut fonctionner.

Elle sert pour les sauvegardes de la configuration (en vue de leur restauration éventuelle), notamment avant chaque mise à jour de firmware, mais également pour le Recovery, c'est à dire le retour à une configuration usine en cas de crash de la box.

Pour rappel, cette clé est connectée sur un port USB situé derrière la plaque métallique vissée sur le coté gauche de la box.

Avant de retirer la clé USB Recovery de la box, s'assurer que celle-ci soit bien éteinte.

Dans un premier temps, nous connectons la clé USB sur un PC sous Windows.

Dans l'explorateur, nous voyons apparaître une partition d'environ 2 Go :

Contenant 3 répertoires et 1 fichier :

24/10/2014  07:44    <REP>          backups
02/09/2013  15:40    <REP>          system
30/08/2013  12:15                10 network.conf
13/11/2013  22:48    <REP>          logs

Il est inutile à ce stade là de vouloir copier l'arborescence de cette partition, car le Gestionnaire des disques de Windows nous montre 2 partitions inconnues supplémentaires, ainsi que de l'espace libre :

La clé a en réalité une taille de 8 Go, mais seuls 4 Go sont utilisés.

Il faut donc monter la clé USB sur un système Linux, qui est capable de lire (presque) tous les formats de partitions existants.

J'ai utilisé pour cela une VM sous ESXi sur mon serveur HP Proliant G7 N54L, voici les captures d'écran des fenêtres de modifications des paramètres de la machine virtuelle :

On remarque que la clé fournie par Fibaro est de marque Kingston, on n'est donc pas en présence d'une clé chinoise premier prix :

Dans ma VM, il s'agit d'un Linux RedHat Enterprise Server, mais n'importe quel Linux peut faire l'affaire, en particulier Debian qui est la distribution utilisée par FIbaro.

Il est évidemment possible de monter cette clé sur n'importe quelle machine Linux, dont voici une liste non exhaustive :

- Linux natif sur PC

- Linux sur Raspberry PI

- Linux dans une VM sous VMware Player sous Windows ou MacOS

- LiveCD bootable sur CD ou clé USB

- etc...

Je ne détaille pas ces procédures, de nombreux tutoriels existent sur Internet, et je répète que si vous voulez tenter les manipulations décrites ici cela nécessite d'être suffisamment à l'aise avec Linux (ce qui implique de savoir l'installer).

Une fois la clé connectée sur la machine Linux, on la voit apparaître dans les messages du noyau avec la commande dmesg :

[root@redhat ~]# dmesg  | tail -21
usb 1-2: new high speed USB device number 3 using ehci_hcd
usb 1-2: New USB device found, idVendor=13fe, idProduct=4100
usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-2: Product: FIBARO RECOVERY
usb 1-2: Manufacturer: FIBARO
usb 1-2: SerialNumber: ......................
usb 1-2: configuration #1 chosen from 1 choice
scsi4 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usb-storage: device scan complete
scsi 4:0:0:0: Direct-Access     FIBARO   FIBARO RECOVERY  PMAP PQ: 0 ANSI: 6
sd 4:0:0:0: Attached scsi generic sg3 type 0
sd 4:0:0:0: [sdc] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
sd 4:0:0:0: [sdc] Write Protect is off
sd 4:0:0:0: [sdc] Mode Sense: 23 00 00 00
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sdc: sdc1 sdc2 sdc3
sd 4:0:0:0: [sdc] Assuming drive cache: write through
sd 4:0:0:0: [sdc] Attached SCSI removable disk

Dans cet exemple, le device utilisé est /dev/sdc

Par curiosité, avec lsusb on peut obtenir des informations sur cette clé Kingston :

[root@redhat ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 196d:f100
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 003: ID 13fe:4100 Kingston Technology Company Inc.

[root@redhat ~]# lsusb -s 001:003 -vvv
Bus 001 Device 003: ID 13fe:4100 Kingston Technology Company Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x13fe Kingston Technology Company Inc.
  idProduct          0x4100
  bcdDevice            1.00
  iManufacturer           1 FIBARO
  iProduct                2 FIBARO RECOVERY
  iSerial                 3 ......................
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              200mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0000
  (Bus Powered)

Avec la commande parted, on découvre plus en détail la structure des partitions de cette clé :

[root@redhat ~]# parted /dev/sdc
GNU Parted 2.1
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: FIBARO FIBARO RECOVERY (scsi)
Disk /dev/sdc: 8011MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system     Flags
 1      1049kB  2000MB  1999MB  primary  fat32
 2      2000MB  2255MB  256MB   primary  linux-swap(v1)
 3      2255MB  3817MB  1561MB  primary  ext4            boot

(parted) quit

La taille de 8 Go est confirmée.

On trouve les partitions suivantes :

FAT32 (la partition visible sous Windows)
Linux Swap (l'espace de paging space du système Linux)
ext4 (le format de fichier standard d'une partition Linux, et qui se trouve en plus être bootable)

Sauvegarde de la clé

Sans plus attendre, on procède immédiatement à la sauvegarde cette clé, ce qui est l'étape la plus importante de cette étude.

On utilise pour cela la commande dd qui permet de réaliser une copie bit-à -bit de l'intégralité de la clé.

[root@redhat ~]# dd if=/dev/sdc of=/tmp/usb.img bs=1M
7640+0 records in
7640+0 records out
8011120640 bytes (8.0 GB) copied, 812.817 s, 9.9 MB/s

Débit moyen de lecture de 10 Mo/s, ce n'est pas terrible (le débit max du bus l'USB-2 étant d'environ 25 Mo/s), mais pour l'usage très occasionnel qui est fait de cette clé, ce n'est pas un souci.

On obtient un fichier de 8 Go sur le disque dur, qui est l'image exacte de la clé :

[root@redhat ~]# ls -l /tmp/usb.img
-rw-r--r--. 1 root root 8011120640 Oct 24 10:35 /tmp/usb.img

Ce fichier contient donc le MBR (Master Boot Record) de la clé, l'intégralité des 3 partitions, ainsi que l'espace vide, comme le confirme la commande file :

[root@redhat ~]# file /tmp/usb.img
/tmp/usb.img: x86 boot sector; partition 1: ID=0xb, starthead 32, startsector 2048, 3903488 sectors; partition 2: ID=0x82, starthead 27, startsector 3905536, 499712 sectors; partition 3: ID=0x83, active, starthead 54, startsector 4405248, 3049472 sectors, code offset 0x63

Note : il aurait été possible de réaliser une sauvegarde de façon plus optimisée, en sauvegardant indépendamment le MBR et les 3 partitions, afin de ne conserver que les 4 Go utile. Néanmoins dans ce tutoriel la procédure se voulait simple afin de cloner intégralement la clé USB fournie par FIbaro afin de conserver une copie de secours. Nous verrons peut-être ultérieurement qu'il est possible d'aller beaucoup plus loin dans les manipulations de cette clé.

Restauration de la clé

On connecte une nouvelle clé USB vierge sur le système Linux.

Si cette clé n'est pas vierge, elle sera écrasée.

La restauration de la clé de Recovery utilise toujours la même commande dd, mais en sens inverse, c'est à dire qu'on lit le fichier pour écrire sur le périphérique USB. Dans mon exemple il s'agit de /dev/sdd :

[root@redhat tmp]# dd if=/tmp/usb.img of=/dev/sdd bs=1M
dd: writing `/dev/sdd': No space left on device
7553+0 records in
7552+0 records out
7918845952 bytes (7.9 GB) copied, 703.889 s, 11.3 MB/s

On note une erreur car l'espace disponible sur ma nouvelle clé est insuffisant. En effet, j'ai utilisé une clé qui fait un peu moins de 8 Go, donc la commande n'a pas pu écrire la fin des octets. Ce n'est nullement gênant car comme on l'a vu précédemment, seuls 4 Go sont utilisés et la fin de la clé est inutilisé. Dans l'exemple ci-dessus, 7,9 Go ont été écrits, ce qui est plus que suffisant.

Test de la clé clonée

On insère la clé USB dans la box HC2, on branche l'alimentation, et la box boot comme si de rien n'était.

On l'arrête à nouveau, on rebranche la clé d'origine, et on redémarre la box en production.

On conserve la nouvelle clé générée bien à l'abri, ou pas, puisque avec l'image binaire présente sur le disque dur il est toujours possible de regénérer autant de clés qu'on le souhaite.

Notes complémentaires

Cette procédure permet de cloner une clé devant être utilisé sur la même box. L'étude pour cloner une clé sur une box différente sera menée ultérieurement (sans garantie de succès)

Le clonage de la clé aurait pu se faire directement avec la commande suivante, sans passer par le disque dur (non testé) :

dd if=/dev/sdc of=/dev/sdd bs=1M

.

Analyse détaillée de la clé

A partir de ce chapitre, on commence l'étude approfondie de la clé de Recovery. Par sécurité afin de ne pas tout casser en cas de fausse manipulation, on travaille sur l'image générée précédemment sur disque.

Le fichier usb.img est une image en mode "raw" de la clé, et a donc conservé la structure initiale avec les 3 partitions :

[root@redhat tmp]# parted usb.img print
Model:  (file)
Disk /tmp/usb.img: 8011MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system     Flags
1      1049kB  2000MB  1999MB  primary  fat32
2      2000MB  2255MB  256MB   primary  linux-swap(v1)
3      2255MB  3817MB  1561MB  primary  ext4            boot

On crée les devices dans le noyau permettant de monter les partitions :

[root@redhat tmp]# kpartx -v -a usb.img
add map loop0p1 (253:2): 0 3903488 linear /dev/loop0 2048
add map loop0p2 (253:3): 0 499712 linear /dev/loop0 3905536
add map loop0p3 (253:4): 0 3049472 linear /dev/loop0 4405248

On crée les points de montages (il est inutile de monter la partition de swap) :

[root@redhat ~]# mkdir /mnt/sdc1
[root@redhat ~]# mkdir /mnt/sdc3

On monte les 2 partitions intéressantes :

[root@redhat tmp]# mount /dev/mapper/loop0p1 /mnt/sdc1 -o ro
[root@redhat tmp]# mount /dev/mapper/loop0p3 /mnt/sdc3 -o ro

Dans la partition n°1, on retrouve les fichiers qui étaient visibles sous Windows :

[root@redhat tmp]# cd /mnt/sdc1
[root@redhat sdc1]# ls -l
total 16
drwxr-xr-x. 7 root root 4096 Oct 24 07:44 backups
drwxr-xr-x. 2 root root 4096 Nov 13  2013 logs
-rwxr-xr-x. 1 root root   10 Aug 30  2013 network.conf
drwxr-xr-x. 2 root root 4096 Sep  2  2013 system

Vérification de l'espace occupé/libre :

[root@redhat sdc1]# df -m .
Filesystem          1M-blocks  Used Available Use% Mounted on
/dev/mapper/loop0p1      1903   487      1416  26% /mnt/sdc1

Les tailles de Mo de chaque fichier/répertoire :

[root@redhat sdc1]# du -sm *
63      backups
1       logs
1       network.conf
424     system

On en déduit que sur les 2 Go de cette partition, 424 Mo sont utilisés par l'image système de recovery, et seulement 63 Mo (dans mon cas) pour les sauvegardes de la configuration. Donc les 1416 Mo libres sont plus que suffisants pour réaliser un grand nombre de sauvegardes.

Dans mon cas, j'ai seulement 5 sauvegardes, et on remarque que la plus grosse d'entre elle est ma dernière sauvegarde du 24/10/2014 :

[root@redhat sdc1]# du -sm backups/*
6       backups/backup16_01_14-2032
6       backups/backup16_01_14-2037
41      backups/backup24_10_14-0944
11      backups/backup28_02_14-1428
2       backups/backup29_11_13-0019

Le fichier network.conf contient seulement l'info permettant au réseau de fonctionner en DHCP lorsqu'on boot en recovery :

[root@redhat sdc1]# cat network.conf
type=dhcp

Etudions maintenant le contenu de ma dernière sauvegarde :

[root@redhat sdc1]# cd backups/backup24_10_14-0944/
[root@redhat backup24_10_14-0944]# ls -l
total 40812
-rwxr-xr-x. 1 root root      117 Oct 24 07:44 checksum
-rwxr-xr-x. 1 root root      131 Oct 24 07:44 info
drwxr-xr-x. 2 root root     4096 Oct 24 07:44 scenes
-rwxr-xr-x. 1 root root 41757696 Oct 24 07:44 sql
-rwxr-xr-x. 1 root root    16528 Oct 24 07:44 zwave

Il y a quelques fichiers textes, une base de données SQLite, et un fichier binaire :

[root@redhat backup24_10_14-0944]# file *
checksum: ASCII text
info:     ASCII text
scenes:   directory
sql:      SQLite 3.x database
zwave:    data

Le fichier checksum contient des sommes de contrôles permettant de s'assurer de la cohérence des fichiers stockés sur la clé avant la restauration éventuelle :

[root@redhat backup24_10_14-0944]# cat checksum
82a0e8acacb02838248ff032dfb16a7e  sql
96d7a2aac279dc2be1abd77bb1f37196  zwave
c9bf3777d6c6990e37a59aa3cfac49af  info

Vérification, tout est OK :

[root@redhat backup24_10_14-0944]# md5sum sql
82a0e8acacb02838248ff032dfb16a7e  sql
[root@redhat backup24_10_14-0944]# md5sum zwave
96d7a2aac279dc2be1abd77bb1f37196  zwave
[root@redhat backup24_10_14-0944]# md5sum info
c9bf3777d6c6990e37a59aa3cfac49af  info

Le fichier info contient quelques informations génériques qui sont affichées par l'interface Web lorsqu'on boote la box en recovery :

[root@redhat backup24_10_14-0944]# cat info
devices=90
rooms=12
scenes=22
hour=09
minute=44
day=24
month=10
year=2014
timestamp=1414136694
description=24/10/2014 v3.590 stable

Le fichier sql contient toute la configuration, dont voici un extrait :

[root@redhat backup24_10_14-0944]# sqlite3 sql ".tables"
Alarm_Fibaro_Scene
Alarm_Zone
Alarm_Zone_PIN
Backups
Borrowed_Devices
Cooling_Zone
Cooling_Zone_Room
Dashboard
Device_Association_Group
[...]

Par exemple :

[root@redhat backup24_10_14-0944]# sqlite3 sql 'select * from Room;'
1|1|Salon|room_kominek|999|96|97|0|0
2|1|Entrée|room_kapelusz|999|0|0|0|0
3|1|Salle à  manger|room_jadalnia|999|0|0|0|0
[...]

Dans le sous-répertoire scenes, on y trouve des pages html et des scritps LUA :

[root@redhat backup24_10_14-0944]# cd scenes/
[root@redhat scenes]# ls -l
total 484
-rwxr-xr-x. 1 root root 17288 Oct 24 07:44 10.html
-rwxr-xr-x. 1 root root   828 Oct 24 07:44 10.lua
-rwxr-xr-x. 1 root root 17346 Oct 24 07:44 11.html
-rwxr-xr-x. 1 root root   947 Oct 24 07:44 11.lua
-rwxr-xr-x. 1 root root 19930 Oct 24 07:44 12.html
-rwxr-xr-x. 1 root root  1047 Oct 24 07:44 12.lua
-rwxr-xr-x. 1 root root 17756 Oct 24 07:44 13.html
-rwxr-xr-x. 1 root root   923 Oct 24 07:44 13.lua
-rwxr-xr-x. 1 root root 26374 Oct 24 07:44 14.html
-rwxr-xr-x. 1 root root  1112 Oct 24 07:44 14.lua
[...]

Au hasard, prenons la plus grosse scène, et ô surprise (oui je sais j'utilise encore une veille version de GEA) :

[root@redhat scenes]# head -22 22.lua
--[[
%% autostart
%% properties
46 value
%% globals
--]]
-- ------------------------------------------------------------
-- GEA : Gestionnaire d'Evénements Automatique
-- Scénario permettant de contrôler si une périphérique est
-- activé depuis trop longtemps ou lancer
-- un push d'avertissement
-- L'état du périphérique est contrôlé toutes les X secondes
-- si passer le délai souhaité le périphérique est toujours
-- activé, le système envoi une notification
--
-- Auteur : Steven P. with modification of Hansolo
-- Version : 3.50
-- Special Thanks to :
--  Fredric, Diuck, Domodial, moicphil, lolomail, byackee,
--  JossAlf, Did and all other guy from Domotique-fibaro.fr
-- ------------------------------------------------------------

.

On retourne maintenant à la racine de la partition n°1, afin d'étudier rapidement le répertoire system :

[root@redhat scenes]# cd /mnt/sdc1
[root@redhat sdc1]# cd system
[root@redhat system]# ls -l
total 433920
-rwxr-xr-x. 1 root root        33 Sep  2  2013 checksum
-rwxr-xr-x. 1 root root 444328464 Sep  2  2013 image.gz
-rwxr-xr-x. 1 root root         0 Jul 17  2012 version3
-rwxr-xr-x. 1 root root         0 Aug 23  2013 version4

Comme pour les sauvegardes, une somme de contrôle permet de s'assurer de l'intégrité de l'image à restaurer :

[root@redhat system]# cat checksum
c496e1fe5e3095b73e2f376b35ae5307
[root@redhat system]# md5sum image.gz
c496e1fe5e3095b73e2f376b35ae5307  image.gz

Ce fichier image.gz est une archive compressée d'une image raw d'un disque :

[root@redhat system]# file image.gz
image.gz: gzip compressed data, was "image", from Unix, last modified: Mon Sep  2 15:27:19 2013
[root@redhat system]# gzip -dc image.gz | file -
/dev/stdin: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 1951744 sectors; partition 2: ID=0x82, starthead 157, startsector 1953792, 499712 sectors; partition 3: ID=0x83, starthead 184, startsector 2453504, 1368064 sectors, code offset 0x63

On décompresse cette archive dans un répertoire temporaire :

[root@redhat system]# cd /tmp
[root@redhat tmp]# gzip -cd /mnt/sdc1/system/image.gz > image
[root@redhat tmp]# ls -l image
-rw-r--r--. 1 root root 2002780160 Oct 25 18:26 image

Il s'agit de l'image du disque système interne de la HC2 (clé USB SLC de 2 Go) :

[root@redhat tmp]# parted image print
Model:  (file)
Disk /tmp/image: 2003MB
Sector size (logical/physical): 512B/512B
Partition Table: msdosNumber  Start   End     Size   Type     File system     Flags
1      1049kB  1000MB  999MB  primary  ext4            boot
2      1000MB  1256MB  256MB  primary  linux-swap(v1)
3      1256MB  1957MB  700MB  primary  ext4

En cas de recovery de la box, c'est donc cette image qui est restaurée sur la mémoire interne de la box, puis la dernière sauvegarde peut être restaurée.

Je ne détaille pas plus le contenu de ces partitions systèmes, mais il est tout à fait possible de les monter et d'accéder à leur contenu.

Je précise néanmoins que la première partition est la racine du système (/), tandis que la troisième partition est montée dans /var (contient les journaux, les pages Web, etc...). La première partition (FAT32) de la clé de Recovery est montée dans /home/fghc2-recovery/recovery

On étudie maintenant la partition n°3 de la clé de Recovery :

[root@redhat mnt]# cd /mnt/sdc3
[root@redhat sdc3]# ls -l
total 96
drwxr-xr-x.  2 root root  4096 Dec  8  2011 bin
drwxr-xr-x.  3 root root  4096 Dec  8  2011 boot
drwxr-xr-x.  5 root root  4096 Dec  8  2011 dev
drwxrwxr-x. 74 root root  4096 Aug 30  2013 etc
drwxr-xr-x.  3 root root  4096 Oct  3  2011 home
lrwxrwxrwx.  1 root root    28 Dec  8  2011 initrd.img -> boot/initrd.img-2.6.32-5-686
drwxr-xr-x. 12 root root 12288 Dec 22  2011 lib
drwx------.  2 root root 16384 Dec  8  2011 lost+found
drwxr-xr-x.  6 root root  4096 Dec  8  2011 media
drwxr-xr-x.  2 root root  4096 Oct  3  2011 mnt
drwxr-xr-x.  3 root root  4096 Dec 11  2011 opt
drwxr-xr-x.  2 root root  4096 Oct  3  2011 proc
drwx------.  4 root root  4096 Sep 12  2012 root
drwxr-xr-x.  2 root root  4096 Dec 12  2011 sbin
drwxr-xr-x.  2 root root  4096 Jul 21  2010 selinux
drwxr-xr-x.  2 root root  4096 Dec  8  2011 srv
drwxr-xr-x.  2 root root  4096 Jan  1  2011 sys
drwxrwxrwt.  2 root root  4096 Aug 30  2013 tmp
drwxrwxr-x. 10 root root  4096 Dec  8  2011 usr
drwxrwxr-x. 14 root root  4096 Sep 11  2012 var
lrwxrwxrwx.  1 root root    25 Dec  8  2011 vmlinuz -> boot/vmlinuz-2.6.32-5-686

Il s'agit du système Linux sur lequel la box boot en mode Recovery.

[root@redhat sdc3]# df -m .
Filesystem          1M-blocks  Used Available Use% Mounted on
/dev/mapper/loop0p3      1467   769       624  56% /mnt/sdc3

.

Conclusion

Après un certains nombres d'expériences non décrites ci-dessus :

La restauration du dump sur la même clé fonctionne, j'ai pu rebooter et faire un recovery.
En revanche, la restauration du dump sur une autre clé ne fonctionne pas complètement (certaines fonctionnalités ne fonctionneront pas, comme les sauvegardes, la réinitialisation de la puce Z-Wave, l'exclusion de modules, ... particulièrement en v4 où la sécurité a été renforcée)

En effet, Fibaro utilise cette clé comme un dongle de protection. Les informations utilisées sont situées dans le firmware de la clé, et non sur les cellules flash. Par conséquent, elle ne sont pas prises en compte par la commande "dd".

Donc si la clé est défectueuse (read only, secteurs défectueux, etc...), la méthode officielle est de se rapprocher du revendeur ou de Fibaro pour procéder à un échange.

A noter que dans la mesure où la génération d'une nouvelle clé expose une partie des protections mises en place par Fibaro, ils refusent l'intervention à distance et imposent jusqu'à présent un retour complet de la box.

Cependant, dans le cas où les données de la clé USB sont corrompues, mais que la clé n'est pas physiquement endommagée, il est tout à fait envisageable de reconstruire une clé de recovery from scratch pour les utilisateurs qui n'auraient pas fait de clone préalable.

Il faut simplement les éléments suivants :

- MBR (512 octets)

- archive du répertoire system de la première partition

- image de la seconde partition

Cette expérience a été validée avec succès dans ce topic.

**Lazer** · le 24 octobre 2014

Cartes mères

Il y a au moins 2 versions de la box HC2.

La première version est basée sur une carte mère Intel D945JT

La seconde version est basée sur une carte mère Intel DN2800MT

Pour information, mon HC2 achetée en novembre 2013 est une 2nde version.

Carte mère Intel D945JT

Carte mère : Intel D945JT
Processeur : Atom N270 à 1.60GHz (1 core, 2 threads, 32 bits, 45 nm, TDP 2.5W)
Documentations :
Panneau des connecteurs :
- Il y a un 3ème port USB caché verticalement derrière la plaque, entre le DVI et les 2 USB :

Carte mère Intel DN2800MT

Voici la carte mère glissée en dehors du boîtier :
Carte mère : Intel DN2800MT
Processeur : Atom N2800 à 1.86GHz (2 core, 4 threads, 64 bits, 32 nm, TDP 6.5W)
Documentations :
Panneau des connecteurs :
- Il y a un port HDMI caché, en plus du port VGA :

Remarques communes :

Ces cartes mères sont au format Mini-ITX et de conception Intel, gage de fiabilité, qui n'a rien d'une conception chinoise low-cost.
Fibaro adapte le choix de ses composants en fonction du matériel disponible sur le marché, comme en témoigne ce changement de carte mère et processeur.
La dissipation thermique du processeur est dissipé de façon passive par un gros radiateur dont les spécifications proviennent de Intel même, gage de sérieux. Bien que la carte mère dispose d'un connecteur pour un ventilateur régulé utilisable pour le refroidissement du boîtier, Fibaro a fait le choix d'un refroidissement totalement passif grâce à l'excellente conductivité thermique de son boitier alu. Néanmoins, l'absence de caloducs entre le processeur et le boitier pour transmettre la chaleur laisse présager une température interne élevée.
L'ancien processeur Atom N270 est un peu moins puissant que le nouveau modèle Atom N2800, mais il a l'énorme avantage de consommer moins, donc de chauffer moins. Le comparatif ici : Intel Atom N2800 vs N270
A titre de comparaison, le nouveau processeur Atom N2800 est sensiblement équivalent en performance à l'Atom D2700 utilisé dans le Synology DS412+. Nous avons donc là un processeur avec un gros potentiel, clairement sous exploité sur nos installation actuelles en V3.
Il y a de nombreux ports inutilisés sur la carte mère (USB, SATA, PCI-Express, ...)
Il y a 2 connecteurs de mémoire vive SO-DIMM, dont 1 est utilisé par une barrette RAM de 1 Go.
L'horloge interne a une précision de 13 minutes par an à 25ÂºC, c'est à dire 2 secondes par jour, ce qui explique les dérives constatées par les utilisateurs.
Il y a une pile pour l'horloge RTC. C'est une cause de panne future de la box, la durée de vue d'une pile étant limitée, et lorsque cela arrive, un message au BIOS demande d'appuyer sur un touche, empêchant le démarrage autonome de la box sans écran+clavier. Heureusement cet élément est remplaçable.
L'alimentation externe va de 8V à 19V en courant continu. Cela donne une bonne marge de manÅ“uvre pour le remplacement de l'alimentation fournie. En particulier, je pense alimenter ma box via une alimentation secourue par batterie au plomb dont la tension oscille entre 12V et 13,6V selon la charge. L'efficacité énergétique d'une alimentation secourue étant supérieure à celle d'un onduleur, cela me semble la meilleure option pour sécuriser l’alimentation de notre box.
Il existe une procédure permettant de faire un recovery d'un BIOS corrompu, à partir d'un disque dur, d'un CD, ou d'une clé USB.
En haut à gauche sur la photo de la DN2800MT, on découvre une carte fille avec un stick USB collé dessus.

On trouve cette carte mère pour une 100aine d'euros sur eBay, permettant de la remplacer si besoin pour un cout modéré hors-garantie.

Le seul élément qui ne se trouvera pas dans le commerce est la carte fille de conception Fibaro, que voici retournée :

On découvre que le stick USB collé est en fait la mémoire Flash SLC de 2 Go sur lequel est installé le système.

A noter que j'ai la version 1.3 de cette box (achetée à l'automne 2013).

**Lazer** · le 24 octobre 2014

Voici une vidéo du Boot de la box Fibaro Home Center 2 v3.590 avec un écran branché sur le port VGA/HDMI, avec les diodes de la box afin d'identifier les étapes d'un boot réussi.

Note : la clé RSA sert au tunnel SSH créé depuis la box vers les serveurs de Fibaro quand on a autorisé l'accès distant via http://home.fibaro.com/

Une autre vidéo explorant le BIOS :

On constate une température du processeur de 48°C.

Cependant la box venait d'être allumée, et les capots en alu sur les cotés sont ouverts, favorisant une meilleure dissipation de la chaleur.

Sur une box en production, capot fermé, le processeur est au minimum à 55°C au repos.

**BenjyNet** · le 24 octobre 2014

Ah ! Bien tout ça ! J'aime linux. T'as monté la partition ext4 ?

**Lazer** · le 24 octobre 2014

oui c'est pour la suite

**Krikroff** · le 24 octobre 2014

Très bien ce post, très tres bien ☺. Merci Lazer.

Envoyé de mon GT-P5210 en utilisant Tapatalk

**maestrea** · le 24 octobre 2014

Bonsoir,

Est-ce que le chip zwave est dans une clé USB? à‡a peut-être une possibilité de faire le changement à zwave-plus.

Merci.

**Lazer** · le 24 octobre 2014

Je n'ai pas identifié avec certitude le chip Z-Wave, mais clairement il est soudé sur la carte fille en haut et àgauche de la première photo.

Comme je le décris dans le texte accompagnant la photo (voir mise àjour de mon message), c'est une carte propriétaire Fibaro sur laquelle nous n'avons pas la main. Il s'agit d'ailleurs du seul élément non standard de cette box.

**PITP2** · le 25 octobre 2014

Merci Lazer :60: pour cette superbe analyse

**Rocketlud** · le 25 octobre 2014

Topissime tu es un grand malade.lol j'adore maintenant on attend la suite avec impatience

**Nico** · le 25 octobre 2014

Excellent Lazer. Malheureusement cela me confirme certaine chose du coup :

En prenant une carte mère du marché, Fibaro à fait un bon choix, gage de qualité avec Intel. Par contre ils avaient dessus une série de chose, comme les différents port VGA/HDMI, qui du coup ne serviront sans doute jamais. Ils les avaient dessus, les ont laissés là et voilà . Je pense que beaucoup de chose n'ont jamais prévu été prévu pour être utilisé je pense.

Maintenant hormis la carte spécifique, on aurait presque pu basculer la HC2 dans une VM du coup ??

**PITP2** · le 25 octobre 2014

Je ne suis pas d'accord avec toi Nico.

Il est mieux de s'offrir niveau hardware la possibilité de faire évoluer les choses plutôt que de se dire 2 ans après oh et bien j'aurais bien mis ça et ça et devoir redevelopper pour un nouvel hardware offrant ces possibilités.

De lààdire qu'ils ont pensé àtout utiliser c'est une autre chose...

**Lazer** · le 25 octobre 2014

Faut voir surtout la logique de coût de développement et de production.

Prendre une carte mère du marché et y installer Debian ça ne coûte rien en R&D et c'est rapide àcommercialiser. Le seul travail c'est de réaliser l'interface Z-Wave et le boitier en alu.

Au niveau production, à100€ la carte en prix public, on imagine qu'ils ont négocié un prix de gros, et on est sur du standard, il est facile de s'approvisionner chez un autre fournisseur en fonction de l'évolution du marché. D'ailleurs je suis persuadé que les premières HC2 ont un processeur un peu moins puissant.

Reste qu'on a làune carte mère avec un grand nombre d'entrées sorties, qui ne seront jamais exploitées, mais c'est du bonus qui vient avec la carte, non nécessaire pour l'objectif premier de domotique.

Le fait que le port HDMI soit caché démontrent qu'il n'a jamais été question d'en faire autre chose, et pourtant c'est bien dommage, car quand on voit l'évolution du marché (Apple TV), une box domotique fanless pilotable depuis la TV ce serait un carton.

Idem pour la sortie audio, il y a le connecteur numérique SPDIF sur la carte mère.

**Nico** · le 25 octobre 2014

Exactement Lazer, c'est pour ça que je disais ça PITP2. Je pense que tout cela ne serai jamais utilisé. D'ailleurs ce n'est pas l'objectif premier d'une box domotique. Mais cela viendra peut être.

Par contre je comprend moins le bridage de la clef USB à 2go, alors qu'elle en fait 8, car niveau sauvegarde, on aurait tout de même pu en faire nettement plus...

**Lazer** · le 25 octobre 2014

La clé USB recovery utilise 4 Go, comme mentionné dans les specs initiales de Fibaro. La mienne fait 8Go certainement pour des raisons d'approvisionnement car le matos a évolué entre temps. Qui peut le plus peut le moins, mais ce n'est qu'une clé de recovery, rien de plus. L'espace de 2 Go alloué aux sauvegarde est déjàtrès largement surdimensionné.

En interne, nous avons la clé de 2 Go de de flash SLC pour le système, la config, les logs, etc...
La SLC c'est performant, fiable, mais... Cher !
A priori les 2 Go semblent suffisant pour le besoin de notre box. Restera àvoir après 2 ou 3 ans de statistiques de consommation et température si c'est suffisant ou pas.

**BenjyNet** · le 25 octobre 2014

Bon si je comprends rapidement le truc, on se retrouve tout bêtement avec une base x86, un linux, un ssd de 2Go pour l'OS et une carte zwave en usb2. La dissipation du pross est finalement banale et la boite en Alu n'est là que pour le design (sans contact, ni pate thermique il y a une moins bonne dissipation thermique).

Mais pourquoi ne pas avoir prévu un ssd plus important ? Pourquoi ne pas avoir pensé à une box domotique utilisable sur une tv ? Ils ont dans les mains une plateforme puissante, sous exploitée.

Le coup de la mémoire de 2Go me laisse perplexe quand même !

**Lazer** · le 25 octobre 2014

Oui je me suis fait la même remarque au sujet de l'absence de contact thermique entre le proc et le boitier

Pour la 2 Go, voir ma réflexion du dessus.

**BenjyNet** · le 25 octobre 2014

Oui je suis un peu dubitatif... moi qui espérait voir arriver plus de suivis conso/temp/hum. Je ne sais pas en même temps combien ça peut prendre d'espace disque (même si la retenue de Fibaro n'est qu'annuelle). Mais franchement 2Go ! C'est super limite quoi ! Et quand on voit le matériel à l'intérieur de la boite, on se dit que le tarif de 599â‚¬ est exagéré !

Edit : Lazer, par curiosité et comme je sais que t'es bien équipé, tu peux me faire une macro recto/verso de la carte Fiabro ?

Modifié le 25 octobre 2014 par BenjyNet

**clarkkent609** · le 25 octobre 2014

ca sent le reverse engineering de la carte fille lol

En tous cas merci pour ces découvertes très intéressantes!

**PITP2** · le 25 octobre 2014

@nico, je n'avais pas bien regardé et en effet rien n'est accessible à l'arrière du boitier pour le HDMI etc donc c'est couillon

**Nico** · le 25 octobre 2014

Lol Lazer, te connaissant cela ne pouvait être que pour tester dans une VM

Mais pour les tailles, comme indiqué je suis dubitatif aussi. Quand j'étais en 4.018, on a accès à l'espace disque utilisé, et je suis déjà bien rempli en fait, plus de 50%... Maintenant il faudra surveiller la croissance, car si cela se trouve le système prend beaucoup, mais tout de même. Et pour les sauvegardes pareil, 2 go c'est juste, car j'étais a 60% de mémoire avec juste quelques sauvegardes.

**Krikroff** · le 25 octobre 2014

De mon côté,

- le HC2 sur board PEGTRON: pas de hdmi et 2 ports USB, Clé 4Go (Pas regardé le vendor ID)

- le HC2 sur board MITAC: vga + hdmi et 4 ports USB, Clé 4Go (Kingston)

Les partitions sur la clé:

Sous windows le soft HDD Raw copy Tool réalise bien un clone, je boot sans problème avec un clone de la clé 4Go Kingston sur une 8Go Sandisk.

En revanche, peut-être une limite du clone avec Raw Copy (mais j'en doute), impossible de faire un backup "visible" pas le HC2, Lazer tu as essayé de faire un backup / restauration avec ton clone ?

**Lazer** · le 25 octobre 2014

@Benjy, @Nico : avant d'en tirer des conclusions hâtives sur la taille de la clé 2 Go, attendez que je dissèque le truc. Perso je ne suis pas si pessimistes que vous (grâce à ce que j'ai déjà pu apercevoir, et aussi par rapport à l'expérience de mes données en base MySQL externe pour les graphs)

@Krikroff :

Ta capture d'écran confirme que le partitionnement est le même quelque soit la taille de la clé. Ils ont dont le même master quel que soit le fournisseur/modèle/taille de clé USB.

En ce qui concerne les sauvegardes/restaurations, il faut que je refasse des tests, je n'ai pas pensé à tout sur le moment (et je n'avais pas suffisamment de temps hier matin)

**Nico** · le 25 octobre 2014

Lazer, tu verras en V4, la place occupée est déjà très importante. Maintenant comme dit, il ne faut pas oublier le système qui prend peut être déjà beaucoup, tu nous diras. D'ailleurs tu as fait également un clone de la clef SLC ?

Sinon pour le prix, oui et non. Je pense qu'il ne faut pas faire le calcul comme, il reste la R&D derrière pour mettre tout cela au point, le faire vivre, etc. Quand on regarde la Zibase Pro + à côté, qui vaut 379,00 â‚¬, bah c'est autre chose comme daube niveau hardware et software ! Je pense que la marge est bien plus importante dessus.

**Lazer** · le 25 octobre 2014

Oui oui je suis d'accord, il ne faut pas regarder que la marge brute, cela ne suffit pas àfaire un business florissant.

Déjàfaut se concentrer sur l'objectif premier : sécuriser la clé Recovery, et trouver le moyen d'en générer une nouvelle pour le dépannage d'urgence.

Tuto HC2 Hc2 Usb Recovery Tweaks

Messages recommandés

Lien vers le commentaire

Partager sur d’autres sites

Meilleurs contributeurs dans ce sujet

Jours populaires

Meilleurs contributeurs dans ce sujet

Jours populaires

Messages populaires

Lazer

Lazer

Lazer

Images postées

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites

Lien vers le commentaire

Partager sur d’autres sites