JacquesF

Le loader 1.04b existe mais si je me souviens bien il ne va que pour le DS918. Si le câble est direct entre le PC et le NAS, il devrait être croisé. Mais si ce sont des interfaces Gigabit des 2 côtés, ça se débrouille tout seul en principe (les 8 fils servent en 1Gb, 4 en 100Mb et 10Mb). Regarde via le port série (câble croisé ncessaire) pour savoir ce qui se passe une fois le loader chargé, tu dois voir une sortie avec la configuration réseau des cartes si tout se passe bien. Sinon, tente avec le extra-lzma2 (voir les différents posts de IG-88 sur ce sujet, ou des tutos sur les migrations. Jacques

Content de savoir que ça a marché ! Je te conseille de profiter de l'occasion pour faire des copies d'écran de chaque page de configuration, tout n'est pas dans la sauvegarde en tout cas (fichier .dss si je me souviens bien). Dans les commandes données je ne vois rien qui puisse avoir effacé les données du raid md0, tout au moins tant qu'on a pas du avoir à le récréer en entier et bien sur tant qu'il n'a pas été formaté. Mais le raid avait disparu avant. Je pense que c'est la migration de l'assistant qui a planté le DSM complètement, d'où la perte de la configuration, mais difficile à confirmer à distance. Pour tes données, je te conseille tout de même de sauvegarder les plus importantes ailleurs. L'architecture du volume de données est la suivante : - md2 : raid 5 sur les 7 disques pour un espace de 5,5*(7-1) To, soit 32,74 To (tolérance de panne 1 disque) - md3 : raid 1 sur les 2 disques de 9 To (miroir) pour un espace de 3,65*(2-1) To soit 3,65 To (tolérance de panne 1 disque A ou B) Le tout en JBOD dans le volume vg1 ce qui fait 32,74 + 3,65 = 36,39 To si je ne me trompe pas. Les disques A et B sont donc critiques, même si ils ne seront peut-être pas remplis tant que le premier raid md2 ne sera pas saturé. Je te rappelle juste que le raid n'est pas un mécanisme de sauvegarde mais une sécurité physique. Ensuite, c'est vrai qu'un volume de données pareil est difficile à sauvegarder... C'est toujours le problème "où mettre tous les œufs ?" en principe pas dans le même panier... Perso, j'ai un NAS de 12 To (4x4 To en SHR), un serveur avec 12 To de stockage aussi (4x4 To en raid 5) et un PC avec 28 To de disques, dont 2x4 To en raid 1 avec mdadm (je suis sous Linux depuis le siècle dernier), ce qui fait 24 To de données possibles sur ce PC. Les vidéos et photos du NAS sont aussi sur mon PC perso, les sauvegardes des configurations (serveur, nas, pc, switch, images de disques, etc...) sont réparties sur les différentes machines et dans le cloud pour les plus critiques. J'ai aussi un vieux Syno avec 1 To de données pour d'autres sauvegardes. Si un disque casse, je n'ai pas trop de risque de perte (surveillance constante de l'état de ceux-ci), maintenant si la maison brûle, il restera le cloud. Bon courage pour la reconfiguration, vérifie que le gestionnaire de disques ne donne pas d'erreur à propos du DSM avant de commencer. Bonne fin de WE Jacques

2,38 Gb c'est bien la taille du DSM en effet. Donc, c'est OK

Si un fdsik -l /dev/md0 donne bien une taille de 2,4 Go (ce qui devrait être le cas vues les infos du dstat), alors il n'y a pas de système de fichiers dessus. Je suppose que mount tente d'abord les OS linux puis passe la main à ntfs3g pour accéder aux partitions NTFS de Windows, d'où le message d'erreur. Donc créer un système de fichiers pour md0 (si il fait bien la taille prévue) : mkfs.ext4 /dev/md0 Ensuite, redémarrage, puis installation from scratch du DSM sans toucher à la partition de données. J'espère que c'est la dernière fois...

Oui, pas normal qu'il essaie de monter le volume à la place du raid md0.

Attention, ça c'est le volume des données (/dev/mapper/vg1000-lv). Es-tu sur d'avoir tenté de monter md0 ? Dans le doute, si l'erreur persiste avec md0, redémarre sur Ubuntu et fait juste la première commande pour construire les raids en auto (mdadm -Asf, pas de vgchange -ay). Comme ça le volume des données restera dans l'état (ce qui n'empêchera pas les 2 raids qui le composent d'être accessibles).

Tu peux tenter de monter le raid effectivement, voir si les données sont présentes. Si le fichier VERSION est là (dans le répertoire de montage suivi de /etc/VERSION c'est à dire /mnt/nas/etc/VERSION par exemple), c'est que les données sont toujours là. Dans ce cas, vérifie avec ls -la /mnt/nas/.xpe* s'il n'existe pas de traces de l'installation précédente. Si oui, efface les comme indiqué dans le tuto initial. Au besoin, tu peux modifier le fichier VERSION pour indiquer une version inférieure, le mien est comme ça (toujours en 6.1 car je n'avais pas le temps de chercher une carte réseau compatible : root@Maison:/var/log# cat /etc/VERSION majorversion="6" minorversion="1" productversion="6.1.7" buildphase="GM" buildnumber="15284" smallfixnumber="3" builddate="2018/12/26" buildtime="08:39:07" Si le fichier est absent, l'assistant devrait proposer d'installer.

Ou alors tente en ajoutant missing autant de fois que le disque est manquant (10 fois si on en ajoute 6 de A à F), pas de risque à tester

To create a "degraded" array in which some devices are missing, simply give the word "missing" in place of a device name. This will cause mdadm to leave the corresponding slot in the array empty. For a RAID4 or RAID5 array at most one slot can be "missing"; for a RAID6 array at most two slots. For a RAID1 array, only one real device needs to be given. All of the others can be "missing". D'après le manuel, les disques manquants ne devraient pas poser de problème pour le raid1 ou je traduis mal... Dans ce cas, réduit le nombre de devices de 16 à 6 et le DSM se débrouillera après.

Ajoute missing à la fin de la commande, ça devrait aller avec ça Le DSM prévoit de s'installer sur tous les disques (16 dans le type émulé par le XPeno dans ton cas) mdadm --create --verbose /dev/md0 --level=1 --raid-devices=16 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 missing

Je créerai sans le disque sdh (ou sdg). Le DSM se débrouillera normalement pour l'ajouter ensuite, il devrait considérer ça comme le rajout d'un disque ensuite. Sinon on verra ensuite à le rajouter à la main s'il ne veut pas. De toute manière, le système tournera puisqu'il suffit d'un seul disque en état pour lancer le DSM (mirrorring sur tous les disques en partition 1). pas de raid md0 en effet.

Oui, c'est ça. Si on passe au point 5, voici les étapes suivantes : Point 6, on formate le md0 après création (une fois les disques synchronisés dans mdstat). Point 7, on relance l'assistant et on redémarre le NAS sur la clef pour installer.

Possible, je n'ai pas fait de réinstallation from scratch depuis longtemps. Si l'assistant ne propose pas d'installer, dans ce cas redémarre sur le CD, recheck le raid pour que md0 soit assemblé, vérifie que sa taille est bien de 2,4 Gà (via fdisk -l /dev/md0 par exemple) et dans mdstat il s'agit bien de la partition 1 des disques concernés. Ensuite, formate le via mkfs comme indiqué plus haut et redémarre sur la clef en mode installation. Je doute que l'assistant propose de migrer en ce cas.

Pas la peine de tenter une restauration, de mémoire en double cliquant sur le NAS détecté par l'assistant, ou un clic droit ?, on peut choisir d'installer ou de réinstaller. Là il faut refaire une installation, la partition DSM doit avoir des trucs pas clairs, et je ne peux pas te guider sur ce point suffisamment, ce n'est pas un linux standard, beaucoup de choses sont déplacées dans d'autres répertoires. Et puis, avec ce type de soucis, une installation propre est préférable, même si tu devras reconfigurer des accès et autorisations manuellement, c'est plus fiable. Si l'assistant persiste à vouloir le migrer, on effacera les données du raid md0 avant de le relancer une fois de plus avec un formatage de ce genre : mkfs.ext4 /dev/md0 (après avoir vérifié que le raid md0 correspond bien aux disques concernés et qu'il fait bien 2,4 Go) Là il ne restera pas grand chose de l'installation précédente et l'installeur devrait bien passer à la partie installation !

Le disque sdh est bien celui de 6To qui devrait être en sdg (pris par la clef USB) ? Si oui, on a deux options : - recréer le raid md0 manuellement (le tout a du être défait par l'installeur hier) - voir si l'installeur veut bien le recréer de lui-même avec les caractéristiques prévues selon ton NAS émulé par Xpenology en tentant une nouvelle installation. Si ça marche dans ce cas, vérifie bien que la carte réseau est reconnue dans la version de DSM installée (ancienne clef de boot à restaurer, ou éventuellement fichier extra.lzma à mettre sur la clef). Pour le refaire à la main, une commande comme ceci devrait aller : mdadm --create --verbose /dev/md0 --level=1 --raid-devices=16 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdh1 Le dernier disque (sdh1) m'ennuie car quand on listait l'état du raid hier il donnait la liste des disques avec les noms des disques présents à la création et non pas au moment de la commande Examine : 0 0 8 1 0 active sync /dev/sda1 1 1 8 17 1 active sync /dev/sdb1 2 2 8 33 2 active sync /dev/sdc1 3 3 8 49 3 active sync /dev/sdd1 4 4 8 65 4 active sync /dev/sde1 5 5 8 81 5 active sync /dev/sdf1 6 6 8 97 6 active sync /dev/sdg1 7 7 0 0 7 faulty removed 8 8 0 0 8 faulty removed 9 9 0 0 9 faulty removed 10 10 0 0 10 faulty removed 11 11 0 0 11 faulty removed 12 12 0 0 12 faulty removed 13 13 0 0 13 faulty removed 14 14 0 0 14 faulty removed 15 15 0 0 15 faulty removed soit sdg1 et non sdh1. J'aurai tendance à ne pas ajouter ce disque au raid, ce qui devrait être fait à l'installation ou au redémarrage après installation (une alerte du DSM comme quoi le raid doit être réparé ce qui devrait rajouter le dernier disque automatiquement. Ensuite, suivre la progression de la construction dans le fichier /proc/mdstat Une fois terminé, tenter de monter le raid md0 et voir s'il existe encore des données (si l'installeur n'a pas formaté le raid, c'est encore possible). Perso, je ferai d'abord le test de laisser l'installeur faire le job, sans formatage de la partition de données bien sûr. Jacques

Pas de raid md0 en effet. Que donne l'examen des disques A à F en partition 1 : mdadm -E /dev/sd[a-f]1 Le disque SDA doit être déjà vu comme retiré suite aux manips d'hier soir, donc on devrait pouvoir l'ajouter. S'il faut recréer tout le raid md0, on le fera mais il faudra faire attention au nom de la machine qui est stocké dans le superblock. Pas certain que DSM s'en serve, mais on ne sait jamais.

Que donne le contenu de mdstat : cat /proc/mdstat

Tu n'as pas du faire les commandes données au début du premier tuto pour scanner les disques et créer les volumes : mdadm -Asf && vgchange -ay

Le disque ne semble pas être en faute (pas de secteurs réalloués entre autre (Reallocated_Sector_Ct à 0) mais il y a un paquet d'erreurs de lecture rattrapées (Raw_Read_Error_Rate et Hardware_ECC_Recovered à 70639695) et c'est probablement lié à des erreurs de positionnement du disque (Seek_Error_Rate à 4290801989). Peut-être des erreurs de cache ? Donc, on peut tenter de reconstruire le raid en sortant le disque et en le remettant. Le lien suivant donne une procédure qu'on va adapter puisqu'on ne va pas remplacer physiquement le disque : Replacing a Failed Mirror Disk in a Software RAID Array (mdadm) 1) Sortir le disque du raid md0 : mdadm --manage /dev/md0 --fail /dev/sda1 mdadm --manage /dev/md0 --remove /dev/sda1 2) Le réinsérer mdadm --manage /dev/md0 --add /dev/sda1 3) Vérifier l'état du raid mdadm --detail /dev/md0 4) Suivre la progression de la reconstruction (devrait être assez rapide : 2,4 Go seulment) cat /proc/mdstat 5 opur l'afficher toutes les 30s par exemple : watch -n 30 "cat /proc/mdstat" A suivre ensuite Jacques

Déjà vérifier l'état du disque SDA avec les commandes smartctl, pour savoir s'il faut remplacer le disque ou non. On verra après le résultat du test. Si le disque est suffisamment en état, on peut tenter de retirer le disque du raid md0, puis de le rajouter en le déclarant sain, ou de forcer son état en sain même sans le retirer, faudra que je révise les commandes mdadm pour ça. Ensuite, si le raid md0 est complet, le reformater en ext4 et refaire une installation (ne devrait plus proposer de récupérer le DSM). Ça c'est dit de tête, à confirmer avant de faire ! Jacques

Bonjour, Je pense qu'on est arrivé aux limites des possibilités de l'installeur de Synology. Il y a un disque en faute pour le DSM (sda1) et on ne peux pas retirer le disque sans risque pour les données (en raid5 donc avec 1 seuil disque en tolérance de panne). Si tu as une sauvegarde complète de tes données (et des packages installés éventuellement), tu peux tenter directement de réinstaller le DSM (sans passer par la phase récupération), cela forcera le système à formater la partition sda1 et à refaire le raid md0. Si tu n'as pas de sauvegarde, alors le plus urgent est d'en faire une au cas où, et pour celà il te faut un LiveCD avec les outils LVM. Dans les essais hier, les commandes lv et vg semblaient ne pas exister, aussi je te suggère de récupérer l'iso de RescueCD et de suivre le tuto surleur sitepour créer une clef USB avec. Ce CD offre quasiment tous les outils de récupération indispensables pour les situations de crise et entre autre mdadm et LVM. De cette façon, en suivant les tutos précédents, tu pourras remonter le raid SHR des données. Ce dernier est (d'après les infos données) composé avec les raids md2 et md3 dans un même volume (vg1 en principe). Le risque est que les données du disque SDA empêchent de remonter le md3 et donc de reconstruire le volume, d'où le fait qu'il vaut mieux conserver le disque sda présent lors des tentatives de réinstallation du DSM (sauf erreur de ma part, je ne suis pas expert dans l'architecture du NAS syno). De toutes façons, il serait plus qu'intéressant de connaître l'état réel du disque SDA, et avec RescueCD, tu peux utiliser ces commandes : smartctl -d sat -a /dev/sda Tu vas obtenir un affichage des caractéristiques du disque et l'état des différents compteurs d'erreur ou d'informations, ainsi que les résultats des derniers tests SMART. SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 28131 - # 2 Short offline Completed without error 00% 27461 - # 3 Short offline Completed without error 00% 26724 - Ceci est la sortie d'un de mes disques sur mon NAS. Si les derniers tests affichent des erreurs, je te conseille de relancer un test court pour avoir le résultat, puis un long (et là sur 9To ce sera long... - Test court : smartctl -d sat -t short /dev/sda - Test long : smartctl -d sat -t long /dev/sda La commande retourne le temps nécessaire pour obtenir le résultat (visible aussi dans la sortie faite avec -i dans la section START OF READ SMART DATA SECTION Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 472) minutes. Conveyance self-test routine recommended polling time: ( 5) minutes. Les résultats du test sont lisibles avec l'option -a par exemple (commande du début). ou -H (health = santé). Si le disque SDA est en faute, il est préférable de le remplacer maintenant. En regardant les structure des raids md2 et md3 je viens de voir que md3 (partions sda6 et sdb6) est de tye raid1, donc du mirroring, ce qui fait qu'on peut récupérer les données aussi bien sda1 (type raid1 aussi pour md0) et sda6 depuis le disque SDB, ce qui est plutôt bon signe. Comme md3 est de type raid1, le disque SDA ne devrait pas empêcher de monter les raids md0 et md3 (en le déclarant en faute (option -f de mdadm) et ensuite de remonter le volume pour finalement monter le tout dans un point de montage (ex : mkdir /mnt/data suivi du mount indiqué pour les datas dans mes messages précédents en utilisant /mnt/data plutôt que /mnt/nas ce qui permettra d'avoir accès aux deux DSM et DATA). Si le disque ne sort pas de faute, alors on avisera pour recréer le raid et reinstaller le DSM dessus. Mais pour le moment, je considère que la priorité est de récupérer les données. Pendant le temps des tests SMART, tu auras le temps de chercher à te documenter sur mdadm, lvm et smart... que ce problème serve ainsi à te faire grinmper en compétences sous Linux et les disques durs. Ça peut toujours servir... à toi ou à d'autres par la suite. Jacques

Il faut supprimer les traces de linstallation : Si tu est dans le chroot : rm -rf /.xpenoboot Si tu est dans le shell ubuntu : rm -rf /mnt/nas/.xpenoboot Ensuite, comme je l'ai dit dans mon message, exit du chroot, démonter le /mnt/nas et redémarrer. Au reboot, voir si Synology assistant trouve le NAS et dans quel état il le voit, ensuite on peut en principe le réinstaller depuis l'assistant, ou depuis l'interface Web, sans formater la partition de données bien entendu. Bonne nuit Jacques

Ça c'est normal, il n'y a pas de fichier VERSION à la racine du disque... Je ne crois pas avoir écrit de lire ce fichier à la racine mais dans le dossier /etc (après avoir fait le chroot). De toute manière, le DSM est accessible et monté sous /mnt/dsm qui devient donc la base du chemin à ajouter devant toutes les commandes du tuto de récupération (les commandes étant indiquées en SSH directement sur le NAS), ou alors faire auparavant un chroot /mnt/nas pour que ce répertoire deviennent la nouvelle racine du shell, et donc les chemins sont à ce moment conformes à ceux indiqués pour SSH. Je te conseille cette option, ça évite des erreurs. Il n'y a pas de raison que le chroot échoue (sauf si tu te trouves déjà dans le dossier /mnt/nas peut-être, auquel cas il suffit de taper cd /mnt pour revenir un cran plus haut. Ensuite, le fichier VERSION est à modifier, si tu n'as pas l'habitude des éditeurs comme nano ou vi, ça peut être un peu compliqué. La solution serait en ce cas, une fois les dossiers xpenoboot supprimé de quitter le chroot (par exit) et de lancer un éditeur de texte graphique (je n'utilise pas gnome, mais de mémoire gedit doit être présent), en faisant un clic droit sur l’icône du menu, il y a peut-être l'option pour le lancer sous root. Sinon, en tant que root dans la console, taper gedit /mnt/nas/etc/VERSION pour éditer directement le fichier (nano n'est pas non plus un éditeur compliqué, les menus sont lisibles en bas). Et si ça marche, je te conseille de remettre la migration à demain, il n'est jamais bon de faire une intervention à risque après pas mal de stress. Je te laisse chercher et suivre le tuto, je repasserai plus tard ou demain matin. Bons tests, et surtout ne te hâte pas... Jacques

Il reste bien les 5 autres disques... Donc, une dernière fois j'espère (le -t ext4 est optionnel) : mount -t ext4 /dev/md0 /mnt/nas Et si ça passe, tu peux reprendre au post indiqué plus haut avec les commandes pour vérifier le fichier VERSION etc..

Essaye avec -f à la place de --faulty, peut-être un problème de version du soft