Aller au contenu

Rechercher dans la communauté

Affichage des résultats pour les étiquettes 'Recovery'.



Plus d’options de recherche

  • Rechercher par étiquettes

    Saisir les étiquettes en les séparant par une virgule.
  • Rechercher par auteur

Type du contenu


Forums

  • Bienvenue
    • Nouveau ? Présentez-vous
    • Le bistrot
    • Mon installation domotique
    • Annonces et suggestions
  • La Home Center et ses périphériques
    • La Home Center pour les nuls
    • HC 2 & Lite
    • HC 3
    • Modules Fibaro
    • Modules Z-wave
    • Périphériques et matériels autres
    • Plugins
    • Quick App
    • Multimédia (audio, vidéo ...)
    • Chauffage et Energie
    • Actionneurs & Ouvrants (Portail, volets, piscines, ...)
    • Eclairage
    • Applications Smartphones et Tablettes
  • Autres solutions domotiques
    • Box / Logiciel
    • Modules Nice (433 & 866 MHz)
    • Modules Zigbee
    • GCE Electronics
    • Modules Bluetooth Low Energy
  • Objets connectés
    • Les Assistants Vocaux
    • Netatmo
    • Philips Hue
    • DIY (Do It Yoursel)
  • Sécurité
    • Alarmes
    • Caméras
    • Portiers
    • Serrures
  • Informatique / Réseau
    • Tutoriels
    • Matériels Réseaux
    • Matériels Informatique
    • NAS
    • Virtualisation
  • Les bonnes affaires
    • Sites internet
    • Petites annonces

Rechercher les résultats dans…

Rechercher les résultats qui…


Date de création

  • Début

    Fin


Dernière mise à jour

  • Début

    Fin


Filtrer par nombre de…

Inscription

  • Début

    Fin


Groupe


Jabber


Skype


Ville :


Intéret :


Version

12 résultats trouvés

  1. "" Recovery en image depuis la version 4.503 en 6 minutes et 10 minutes avec la récupération de la sauvegarde On peut restaurer un fichier de sauvegarde sans avoir a faire un recovery pour le recovery cliquer sur recover Cliquer sur YES On clic sur le drapeau francais Login : admin Password : admin Il ne vous reste plus qu'a restaurer votre sauvergarde
  2. Bonjour à tous, suite à la dernière maj, ma HC2 Reste injoignable. Toutes les leds sont éclairées sauf la dernière (mise à jour) qui clignote. J’ai tenté le mode recovery, puis démarrage sans la clef mais sans succès. La box box reste bloquée avec la dernière led qui clignote..... aidez moi!! Svp. plus sérieusement avez-vous des idées? Une expérience similaire? Merci d’avance à tous je sais que la communauté est super active. Romain.
  3. mprinfo

    Probléme mise a jour suite a recovery

    Probléme mise a jour suite a recovery je viens de faire plusieurs recovery avec différentes images 4.031 et 4.056 avec une clef originale J'arrive toujours au même probléme la restauration ce fait parfaitement. Le probléme arrive lorsque je fais la mise a jour avec les 2 images on me propose les version 4.150 et 4.153b Aprés le mise à jours je reste bloqué sur "Please wait starting services" j'ai fais quelques test en root pour installer d'autres version j'ai sois cette erreur soit une erreur 503 en fonction de la version que j'installe Par contre si je fais un recovery avec l'image 3.548 je passe en 3.600 puis 4.070 puis en 4.150 la aucun soucis
  4. Lazer

    Hc2 Usb Recovery Tweaks

    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.
  5. Bonjour à tous, Ceci est mon premier post sur ce forum que je parcours fréquemment et que je trouve fort intéressant. Je vous explique ma problématique ainsi que le contexte, Je ne connaissais pas du tout FIBARO avant d'acquérir récemment une maison neuve qui est entièrement équipée via une HC2. J'ai voulu associer des interrupteurs à des lampes ou des groupes, créer des scènes qui seraient commandé par un inter. mais sans succès, malgré les nombreux tutos que j'ai pu parcourir. A force de chercher je me suis rendu compte que pour la plupart des interrupteur le retour d'état ne fonctionnait pas. En effet j'ai essayé d'associer des lampes ou scènes avec un interrupteur dont le retour d'état fonctionne et cela a été concluant. Donc la principale cause de mes malheurs était donc le retour d'état, de plus pour information mon système était vraiment très longggggg.... A chaque fois que je cliquait quelque part il fallait attendre plusieurs secondes... Après avoir parcouru le forum je suis tombé sur un post qui parlait de ce problème et qui conseillait de faire un Recovery puis une restauration de la sauvegarde. J'ai réussi a effectuer le Recovery, suite à quoi mon système est extrêmement rapide. C'est le jour et la nuit. Par contre mon système est complètement effacé, j'avais env.150x modules et il n'y a plus rien. Je suis donc allé dans l'onglet Sauvegarde / Restauration et là j'ai bien vu ma dernière sauvegarde mais pas possibilité de Restaurer. J'ai donc refait un Recovery et la comme par magie il y avait l'onglet permettant de restaurer ma sauvegarde. Il y a eu un message disant que la sauvegarde ne doit pas prendre plus de 3 min et qu'il faut actualiser la page au delà . J'actualise et là j'ai un message qui s'affiche "403 ACCES FORBIDEN" et les led sur la HC2 sont différentes que d'habitudes (voir photos jointes).... Et là impossible de faire quelque chose !! Du coup rebelotte Recovery --> Restauration, etc.... je vous passe les détails et "403 ACCES FORBIDEN". Donc en résumé je suis novice, je suis bloqué et je ne sais pas pourquoi je n'arrive pas à restaurer ma sauvegarde? Et vous imaginez bien que je ne me vois pas réinstaller tous les modules de ma maison 1 à 1, sachant que ne saurait même pas comment faire... Si une âme charitable pouvait m'éclairer ce serait avec plaisir .....
  6. Clé Usb Recovery Explication en image de la FAT32 Je vais vous expliquer ce que contient la partition FAT32 de la clé USB Recovery Je précise que ni moi ni le forum de peux être tenu responsable en car d'une mauvaise utilisation de ce TUTO Je ne ferai aucun support sur ce tuto 1 - Il faut eteindre ca box FIBARO via le bouton. 2 - Retirer la clé USB Recovery de la box (je passe le démontage des plaques pour y avoir accés ) 3 - Brancher la clé USB Recovery sur un PC Windows (Pour mac je sais pas si il lit les fat32) 4 - Accéder à la clé USB Recovery via l'explorateur de fichier Windows 5 - Voici ce que vous allez voir : 3 Répertoires et 1 Fichier le fichier network.conf contient la configuration réseau de votre HC2 Passons au répertoire Backups On retrouve ici toutes nos sauvegardes Regardons d'un peu plus prêt une sauvegarde On y trouve 4 fichiers et un dossier scenes checksum = Il contient le numero MD5 pour la vérification de la sauvegarde Info = fichier contenant les infos de la sauvegarde (date, heures, nombres de pièce etc...) sql = base de données sql Regardons de plus prêt le dossier scenes dans le dossier on retrouve tout les scripts de nos scènes ainsi qu'un fichier html par scéne Passons au répertoire log Ce répertoire est vide Le répertoire system checksum : stock le MD5 de l'image (image.gz) image.gz : c'est l'image qui sera restauré lors d'un recovey les fichiers version3 et version4 sont vide Mettre a jour l'image qui sert au recovery Pour cela il suffit de télécharger l'une des images partager par @jojo est de copier les fichiers dans le dossier system https://drive.google.com/drive/folders/0B1AXBMQhZAKAWlpsWk1FTEhlMHM Donc on s' aperçoit qu'il n'est pas très compliquer de faire une copie de ces sauvegardes sur notre PC Pour ceux qui aurait l'idée de modifier la base sql, il faudra recalculer le MD5, mais je dé-conseil de faire cela car en cas d'erreur c'est recovery obligatoirement
  7. Faire un RECOVERY en moins de 30 mn By MPRInfo Tout en Image Comment on passe la box en mode recovery ? (éteindre la box, puis appuyer sur les deux boutons simultanément) Petite précision avant de commencer : J'ai modifié l'image recovery sur ma clef usb, j'ai aussi modifié la taille de la partition fat32 de ma clef recovery de 8go Donc lors de ce recovery je ne vais donc pas passer par la 3.60 mais directement en 4.031 Cela ne change rien au principe pour les box anciennes comme la mienne il faudra passer par la V3 je suis donc en 4.031 pour ceux qui on une image recovery ancienne on doit arrivé en 3.60 si mais souvenir sont bon il faut donc faire la mise a jours pour passer en V4 On passe ensuite en 4.054 Stable On accepte de prendre pleins des risque sans rien dire ou râler Après acceptation il faut parfois re saisir l'adresse de la box pour avoir l'image suivante On ferme le navigateur est on vide le cache comme a chaque mise à jours Ensuite si on veut on peut installer la 4.055B la procédure est la même On oublie pas de nouveau a vider le cache du navigateur une fois la mise a jour faite On ferme le navigateur est on vide le cache comme a chaque mise à jours Pour la clef ou j'ai augmenté la taille voici un aperçu : Liens utiles : Images Clé Usb : https://www.domotique-fibaro.fr/topic/6824-images-clã©-usb/ Clé Usb Recovery Explication En Image De La Fat32 : https://www.domotique-fibaro.fr/topic/5534-clé-usb-recovery-explication-en-image-de-la-fat32/ The END
  8. Faire une copie de la clef usb RECOVERY sous windows Ceci est un complément a ce tuto : http://www.domotique-fibaro.fr/index.php/topic/2364-hc2-usb-recovery-tweaks/ !!! Attention !!! ce tuto n'est pas sans risque si vous ne le suivez pas a la lettre vous risquez de corrompre votre clef USB RECOVERY Il faut télécharger : Win32 Disk Imager : http://sourceforge.net/projects/win32diskimager/ HashMyFiles v2.11 : http://www.nirsoft.net/utils/hash_my_files.html Il faut éteindre la box Retirer la clef USB Recovery pour cela il faut dévissé les 4 vis pour et retirer le cache afin d'avoir accès a la clef Brancher la clef USB RECOVERY sur votre PC Installer Win32 Disk Imager sur votre PC Voici un aperçu des partitions de la clef Lancer Win32 Disk Imager ATTENTION bien cliquer sur READ sinon on risque de détruire la clef usb Notre clef USB et Cloner dans un fichier IMG. Nous allons récupérer le MD5 On copie cette clef MD5 dans un fichier TXT cela nous servira a vérifié si notre fichier IMG n'est pas corrompu lorsque l'on voudra la restaurer. La clef MD5 controler l'intégrité de notre sauvegarde. Cette clef ne changera pas temps que l'on ne modifie pas notre sauvegarde voici un lien qui explique ce qu'est le MD5 : http://fr.wikipedia.org/wiki/MD5 Verification du fichier IMG avec le MD5 On vérifie que la clef MD5 et bien identique a la clef que l'on a copié dans le fichier TXT On copie les fichiers qui ce trouvent sur la partition Fat32 de notre clef USB recovery dans un répertoire de notre PC Répertoires : Backups (contient toutes nos sauvegardes) logs (ce répertoire est vide chez moi system (Contient l'image qui sera restauré lors d'un recovery) network.conf (le fichier contient seulement l'info permettant au réseau de fonctionner en DHCP lorsqu'on boot en recovery) Ce qui nous donne ceci : Avant de faire quoi que ce soit sur votre HC2 Solutions en cas de probléme : Contacter le support FIBARO (surtout si ils peuvent avoir accès à la box) Brancher un écran sur votre HC2 pour voir ce qui ce passent Je précise que le clonage de la clef ne peut normalement être utilisé sur une autre clef USB il faut absolument la clef USB RECOVERY fourni par fibaro
  9. pepite

    Recovery Jeedom Smart

    Bonjour, Le tuto du jour concernant le Recovery sur Jeedom. Ca peut servir http://www.touteladomotique.com/index.php?option=com_content&view=article&id=1938:restore-de-jeedom-smart-la-remise-a-zero-reset&catid=5:domotique&Itemid=89#.WRsW3Uf-DRY
  10. 3e recovery en trois jours, Je fais beaucoup de modifs ces derniers jours en 4.048, tout fonctionne bien, je fais une sauvegarde puis reboot la box et bam erreur 503. Recovery-> retiur en 4.048 puis restauration de ma sauvegarde et bam re erreur 503 Recovery -> et maintenant ça: Et ensuite, en cliquant sur restart, ceci : Est ce que quelqu'un aurait une idée de ce qui m'arrive ? Je tiens àpréciser que la box boot bien en mode normal mais qu'elle m'affiche l'erreur 503 dans tous les cas (Cache vidé etc...)
  11. Note : la gestion des sauvegardes/restaurations/recovery a été totalement modifiée à partir des firmwares v4.500, par conséquent les informations de cette page ne sont pas à jour. Sauvegarde L'onglet Configuration de l'interface Web de la HC2 permet de réaliser manuellement une sauvegarde de la configuration courante sur la clé USB Recovery. De plus, une sauvegarde est effectuée automatiquement avant chaque mise à jour (précisons toutefois que la mise à jour est un processus déclenché manuellement par l'utilisateur dans le panneau Configuration) La sauvegarde contient : la base de données SQLite (définition de tous les modules/périphériques-virtuels/plugins et de leurs paramètres, historique des événements/températures/consommations, etc...) le dump de la puce Z-Wave (modules Z-Wave inclus) les scènes (car leurs codes LUA ne sont pas stockés dans la DB) La sauvegarde ne contient pas : les icônes (elles sont perdues après un recovery) le système (Linux et applications Fibaro) Recovery Le Recovery permet de réinstaller complètement sa box, c'est à dire réinitialiser complètement avec les paramètres usines. Selon les générations de box, le recovery réinstalle complètement la box en v1.x ou v3.548. Il s'agit de la version qui était installée lors de la livraison de la box neuve. Le Recovery est utile dans les cas suivants : Box instable ou complètement crashée Volonté de revenir à une version précédente Volonté de se refaire une réinstallation propre en repartant de 0 Revente de la box Pour accéder au Recovery, il faut éteindre la box, puis appuyer sur le bouton dédié à l'arrière de la box tout en appuyant sur le bouton Power. Selon si on relâche tout de suite le bouton Recovery ou si on laisse le doigt appuyé durant toute la phase de boot, la box prend une adresse IP automatique en DHCP sur le réseau, ou se mettra en IP fixe 192.168.81.1 (auquel cas il faudra paramétrer manuellement la carte réseau de son ordinateur pour accéder à la box). Lorsque la box est bootée en mode Recovery, l'interface Web présente un panneau spécial permettant de lancer la procédure. Cette réinstallation est irréversible et tout ce qui n'a pas été préalablement sauvegardé sur la clé sera perdu. La clé USB Recovery contient une image du système, donc la mémoire interne de la box est effacé, et réécrit à partir de l'image présente sur la clé Recovery. Le second écran propose de réinitialiser également la puce Z-Wave, ce qui est généralement recommandé. De toutes façons, le contenu de la puce Z-Wave sera restauré par la sauvegarde effectuée précédemment (si vous choisissez de la restaurer bien sûr) : Lorsque le recovery est terminé, la box reboote toute seule en mode normal, et l'interface Web de base est à nouveau accessible, avec le compte admin/admin par défaut. La première étape à réaliser sera de mettre à jour la box, en une ou plusieurs étapes selon si l'on souhaite remonter en v3.6 ou v4.x. Restauration La restauration permet de récupérer une sauvegarde préalablement réalisée sur la clé Recovery. Donc les paramètres suivants seront restaurés : la base de données SQLite le contenu de la puce Z-Wave les scènes Les paramètres suivants ne seront pas restaurés : les icônes le système La restauration s'effectue depuis l'interface Web : La restauration peut être lancée juste après un Recovery, ou pas. C'est à dire que l'on peut très bien lancer une restauration par dessus la configuration courante, par exemple si l'on vient d'effectuer quelques modifications qui ont rendu le système instable, sans qu'un recovery soit nécessaire. Puisque qu'une sauvegarde contient le dump de la puce Z-Wave, alors après la restauration il est inutile de réinclure tous les modules inclus avant la date du backup. Il ne sera nécessaire de réinclure que les modules inclus après le dernier backup. Idéalement, on ne fait que des restaurations de configuration à la même version que la version courante. De toutes façons, l'interface Web nous empêche de restaurer une ancienne version qui ne serait pas compatible avec la version courante (notamment entre la v3 et la v4 car les différences sont importantes) Cependant, parfois suite à une mise à jour, la configuration devient instable (modules qui disparaissent de l'interface, etc...). Dans ce cas là , et si on ne souhaite pas se lancer dans une longue procédure de recovery, on peut tenter une restauration de la version précédente. Par exemple : Je fais la mise à jour 4.037 vers 4.040. Des problèmes surviennent, alors je décide de restaurer la configuration 4.037 par dessus mon système qui est en 4.040. A la fin de la restauration, l'interface affiche 4.037, pourtant le système fonctionne toujours en 4.040 (car on l'a vu précédemment, la sauvegarde/restauration ne stocke que la configuration courante, et pas le système). Cet état est dû au code employé par Fibaro qui stocke ne numéro de version courante dans la DB. Donc quand l'interface Web affiche la version, elle va chercher l'info dans la DB, qui n'est plus en phase avec le système. En effet, la mise à jour du champs dans la DB se fait lors de l'install de la mise à jour. De plus, il faut savoir que certaines mises à jour apportent des modifications de schéma à la base de données, et l'ajout de templates de modules Z-Wave. Par conséquent, après la restauration de configuration 4.037, je force une nouvelle mise à jour 4.040, qui ne changera rien au niveau système (puisqu'il est déjà à jour), mais cela permettra de remettre la bonne version dans la DB, et appliquer les éventuelles modifications de schéma. Note : si le bouton de mise à jour n'apparait pas, il est possible de la forcer en appelant directement l'adresse http://IP/services/startUpgrade.php Checksum En v4, une nouvelle fonctionnalité est apparue dans l'interface, permettant de calculer le checkum de l'image de restauration du système présent sur la clé USB Recovery : Il est fortement recommandé de lancer ce calcul de checksum avant de se lancer dans un recovery de la box, afin de s'assurer que l'image est encore valide. En effet, les clés USB sont composées de mémoire Flash qui ne sont pas infaillibles. Pour aller plus loin Afin de sécuriser la clé USB Recovery, vous trouverez (ou devinerez) toutes les réponses à la lecture de mon autre sujet HC2 Recovery Tweaks. [Tuto HC2] HC2 USB Recovery Tweaks Ou pour simplifier, en attendant que Fibaro implémente la fonctionnalité de backup sur un serveur tiers (à priori dans le cloud, je ne suis pas du tout certain qu'ils nous laissent la possibilité de faire du FTP/NFS/CIFS local), vous pouvez simplement arrêter la box, brancher la clé sur un PC, et recopier le répertoire backups. Voir le tutoriel de @mprinfo : [Tuto HC2] Faire Une Copie De La Clef Usb Recovery Sous Windows
  12. PdB

    Sauvegarde Impossible

    Bonjour depuis le passage en 4.036 et 4.037 mes sauvegardes précédentes ont disparu... La tableau Backup reste vide. Quand j'essaie de faire une nouvelle sauvegarde, j'arrive a l'onglet ou il est demandé de donner un nom à la sauvegarde. Puis, le panneau "sauvegarde en cours" apparait 1 sec puis disparait, et pas de sauvegarde..... Une idée d'où cela peut-il venir? D'autres ont-ils eu le meme souci? Merci d'avance.
×