Aller au contenu

eraZor

Membres
  • Compteur de contenus

    33
  • Inscription

  • Dernière visite

Tout ce qui a été posté par eraZor

  1. eraZor

    5.2-5592

    Bonjour, DS-412+ : Je viens de passer de la Version : 5.1-5022 Update 5 === à la ===> Version : 5.2-5592 (soit un saut de 4 versions intermédiaire) sans problème (en tout cas pour ce que j'ai pu vérifier), et ce, en serrant les fesses bien fort et contre toute attente !!! Franchement échaudé après un royal plantage lors du passage en version 5.1-5021, et au regard des messages concernant les différentes dernières mises à jour sur le forum, je n'étais vraiment pas pressé de faire la pas. Cependant, ma configuration ayant été refaite intégralement à ce moment là, peut-être que certaines choses qui n'étaient pas d'aplomb avant l'étaient aujourd'hui pour cette mise à jour ? Pour essayer de limiter les risques au maximum aujourd'hui j'ai : - attendu que ma sauvegarde journalière sur disque externe soit terminée, - downloadé l'archive de la 5.2-5592 correspondant à mon modèle de disque sur mon PC (pas d'utilisation du gestionnaire de mise à jour), - redémarré le Syno avant de commencer l'upgrade, - attendu sagement (et en priant !) que le processus se termine tout seul, sans intervention. Au bout de 10 à 15 minutes j'ai pu avoir accès de nouveau au disque et pu faire les vérifications d'usage. Je reste vigilent, et plus particulièrement vis à vis de la capacité de Synology à nous proposer des upgrade véritablement fiables comme pas le passé. La mise à jour automatique de mon équipement est bien entendu "bannie" en ce qui me concerne, et le passage obligé par le forum quelques jours après une nouvelle sortie d'upgrade est un pré-requis. Bonne journée à tous, et bon courage à ceux qui sont éventuellement plantés. Le bon coté de ce matériel c'est que si aucun truc tordu n'est essayé pour se dépanner, les datas sont en général conservées et récupérables par différents moyens externes... au prix d'un temps conséquent par contre.
  2. eraZor

    Mise

    Merci Gaetan, mais lorsque je disais avoir utilisé toutes les "recettes" que j'ai pu trouver sur le net pour faire un downgrade, j'englobe cette solution de modification des 2 fichiers, et j'étais allé voir ce lien. Sans succès. Même si le DSM m'indique qu'il est dans une plus ancienne version, le rechargement de la 5.1-5004 ne va pas à son terme, car il finit toujours par indiquer que je suis en 5.1-5021 ! Le support me demande ce matin de remettre mon NAS en route et joignable par leur service, afin de régler le problème... A suivre...
  3. eraZor

    Mise

    Petit point après un Noël en famille ! 1°) j'ai passé chaque disque à l'outil constructeur Seagate pour pouvoir répondre au support Synology, puisque c'était l'une de leurs recommandations : rien, nada, les disques n'ont pas de problème à première vue, de plus ils sont toujours visible correctement sur pc ubuntu. J'ai remonté l'info ce matin auprès du support Syno, à voir ce qu'ils diront.... 2°) j'ai remis mes disques dans le NAS, puis j'ai fais un double reset et réinstallé la version 5.1-5021 depuis le Synology Assistant : même punition, le NAS est joignable, les différentes parties semblent fonctionner normalement, mais aucun disque n'est vu (donc pas de volume non plus), et le voyant "status" clignote toujours en jaune/orange. 3°) j'ai viré mes 3 disques, mis un disque de test vide, et fait un reset factory comme si je démarrais à zéro, toujours avec la version 5.1-5021 : même chose que ci-dessus, NAS joignable, le disque n'est pas vu (donc aucun volume non plus), et "status" clignote toujours !!! Ce dernier test tendrait à me faire dire que les disques n'ont rien à voir au problème, que le problème est ailleurs. Remarques : - impossible pour moi de mettre une version autre que 5.1-5021 (5.1-5004 par exemple) dans le NAS, y compris sur un disque "neuf" ! En fait le Synology Assistant voit qu'il est déjà en 5.1-5021 et refuse de passer sur une version antérieure. - j'ai essayé avec toutes les "recettes" que les uns ou les autres ont pu écrire, de changer les fichiers VERSION, rien à faire ! Probablement à cause du fait que le système des NAS est en 2 parties : l'une dans la mémoire/rom + une autre dans une ou plusieurs partition du ou des disques. Lors de l'installation après reset factory, il est bien indiqué qu'il y a formatage de la partition système, installation du DSM, puis des fichiers de config. Donc à mon avis, s'il est prévu d'intervenir dans les partition système pour mettre à jour, il n'y a pas moyen de forcer un downgrade de la mémoire/rom (bios ?) des Syno de manière automatisée. J'ai lu quelques articles sur le sujet, mis à part se connecter en mode console TTY sur le device (ce qui n'est pas prévu sur DS412+ sans le démonter), il n'y a pas moyen de recharger cette mémoire. - lors des différents reboot automatique durant les différentes installations réalisées, j'ai remarqué que le NAS arrive bien jusqu'au reboot (fermeture du système, arrêt du ou des disques, extinction), mais n'arrive que très rarement à redémarrer ensuite normalement. Souvent, le voyant bleu clignote un certain temps (bien trop long > 1h), parfois certain voyant correspondant aux disques sont allumés aussi (c'est pas systématique) alors que le ou les disques n'ont même pas encore démarré (la phase running des disques est en générale lancée vers 40 secondes après l'allumage, on entend bien à l'oreille cette phase), ou que sur ces slots il n'y a même pas de disque ! La majorité du temps, il m'a fallut éteindre en appuie long sur le bouton, ou bien débrancher l'alimentation, attendre + d'1 minutes, et rebrancher ou rallumer, pour que la séquence de démarrage puisse se poursuivre normalement (et le cas échéant, poursuivre l'installation !). Dans l'état actuel, j’attends maintenant un soutient fort de la part du support Synology, car je ne vois pas quoi faire d'autre que de renvoyer le boitier ! Pour moi, l'upgrade en 5.1-5021 est + ou - buggée, à du faire une mise à jour "hardware" coté mémoire interne et cela s'est mal passé pour une raison inconnue. Du coup, je pense que le reste est une conséquence. Nous sommes sans doutes quelques cas isolés à avoir rencontré ce problème sur différents devices, peut-être à cause d'une faiblesse d'un composant interne, ou bien d'un bug aléatoire dans la mise à jour ? Toujours est-il que je trouve scandaleux d'en arriver là pour une boite qui se veut leader en la matière, et qui n'a qu'un seul concurrent sérieux en face. Que penser des update à venir, qui s'ils ne sont pas suffisamment fiable, pourraient conduire à des crashs bien plus généralisés et grave que celui-ci (qui n'est déjà pas mal !) ? Très honnêtement, ma confiance en ce produit à fait une chute d'au moins 50% ! Voilà, à suivre donc...
  4. eraZor

    Mise

    Hello All ! Bon, tant que j'avais les disques montés sur le PC, j'en ai profité pour faire des sauvegarde façon "ceinture et bretelle + parachute" ! La journée d'hier a été consacré à plusieurs rsync en règle afin de tout redonder au maximum ! C'est cool, la maison va ressembler à un datacenter Bref, je pense que je vais remonter les disques dans le Syno et faire le double reset de la mort qui tue pas normalement !!! Cependant, j'ai vu ça sur l'autre forum, quelqu'un aurait-il plus d'infos à ce sujet ? http://forum.synology.com/enu/viewtopic.php?f=250&t=94544&start=45#p357251 Je sais pas si j'attend ou pas... je vais le jouer à pile ou face peut-être ?
  5. eraZor

    Mise

    Bon aller, quelques bonnes nouvelles... J'ai réquisitionné le PC d'un de mes fils, installé sur une SD card un Ubuntu tout neuf, ouvert les entrailles du dit PC, mis en ligne mes 3 disques Raid 5 et quelques instant après le boo.... roulement de tambour.... les 2 volumes sont apparus nickel chrome sans truc foireux !!! I'm happy !!! Il y a même une ligne du tuto trouvé chez Synology que je n'ai même pas eu à taper, le raid est monté direct. Après une balade parmis les fichiers que je croyais avoir perdu et après avoir validé qu'ils semblent être tous en bon état, j'ai même poussé le vice pour éteindre la machine, ajouter le disque de 4To de spare afin de m'en servir de stockage de récupération. Depuis 1h30 c'est en train de tourner ! Y'a pas à dire, le eSata c'est rapide, j'ai bon espoir que ma récupération sera terminée en fin de soirée. L'étape suivant sera, de remettre seulement les 3 disques dans le Syno, et de faire le double reset pour voir si il veut bien repartir. Si cela ne marche pas bien, je n'aurais pas le choix, ce sera reset factory et reconstruction à la mano. Je me demande même si au final je ne ferais pas ça même si ça marche, histoire de repartir sur des bases toutes neuves. Donc pour l'instant je suis donc un peu plus serein. Concernant ce point, j'ai bien l'impression que c'est lorsque le Syno à voulu rebooter à l'issue de l'upgrade, y'a un truc qui a pas fonctionné normalement, du coup y'a surement des trucs qui sont partis en vrille... Je ne vois que ça.
  6. eraZor

    Mise

    Petit historique des upgrade trouvé dans : /var/log/synoupdate.log 2014/12/01 01:02:22 start critical update to buildnumber: 5004 original smallfixnumbre: 0 new_smallfixnumber: 2 build date: 2014/11/29 2014/12/01 01:02:23 Start of the update... 2014/12/01 01:02:31 Congratulation!! The update has been completed!! 2014/12/01 01:02:32 Finished update before reboot! 2014/12/01 08:02:15 Finished critical update!!! 2014/12/16 16:06:26 Start of the update... 2014/12/16 16:06:26 Upgrade from version 5.1.0.5004 to version 5.1.0.5021 2014/12/16 16:07:08 Congratulation!! The update has been completed!! 2014/12/16 18:56:51 Start of the update... 2014/12/16 18:56:51 Failed to accomplish the update! (errno = 10) 2014/12/16 19:25:19 Start of the update... 2014/12/16 19:25:19 Failed to accomplish the update! (errno = 10) 2014/12/17 20:00:16 Start of the update... 2014/12/17 20:00:16 Failed to accomplish the update! (errno = 10) 16h07:08 correspondrait bien au moment ou le Syno à redemarré tout seul.... et n'a jamais pu remonter, il a fallut que je l'arrête "sauvagement" pour qu'il redemarre. C'est peut-être à ce moment là qu'il y a eu un soucis et la perte d'un bout de paramètre concernant l'accès au disques ? Ok merci Gaetan pour ton expertise de qualité. Je vais essayer tout ça au plus vite et ferais un retour bien sur ++
  7. eraZor

    Mise

    Résultat du check de md3 : UIEDS1> cat mismatch_cnt 0 Donc pas d'erreur à priori sur ce raid non plus. Je suis d'accord, y'a pas grand chose de logique dans cette affaire : pourquoi le md3 monte sans problème alors que le md2 non ? Mon plan c'est : 1°) Essayer de monter les 3 disques Raid dans un PC sous ubuntu comme décris dans la base de connaissance Syno, pour voir si j'ai accès aux volumes normalement et aux datas surtout. Si j'accède aux infos, alors je les sauvegardes ailleurs ce sera toujours ça de gagner. 2°) Je remet les disques ensuite dans le Syno et je tente le double reset pour réinstaller DSM : si les données sont conservées et accessible tant mieux, sinon, je ferais un reset factory du Syno afin de repartir sur des bases saines. Question cependant : dans le cas ou je ferais seulement un double reset comme tu l'as indiqué hier, est-ce que je peux restaurer le fichier de config .dss dont j'ai la sauvegarde du 16/12 à 12h, afin de récupérer les infos de comptes, partages, etc... ou vaut-il mieux tout refaire à la main pour repartir vraiment de zero ? Autre point, j'ai comparé des fichier dmesg avant l'upgrade et juste après l'upgrade, je me trompe peut-être, mais j'ai eu l'impression qu'au 1er reboot juste après l'upgrade, une mise à jour firmware dans le bios du Syno a été faite... A suivre...
  8. eraZor

    Mise

    C'est clair, qu'en ce qui me concerne, je me serais bien passé de me retrouver en vrac ! D'un coté, cela m'oblige à m'instruire en profondeur sur Linux, mais d'un autre, j'imagine même pas le boulot qui m'attend si je dois au final repartir de zero ! Enfin je suis content pour toi que tu es échappé à cette galère, cela me conforte dans l'idée qu'il faut toujours différer de quelques jours ou semaines les mises à jours d'à peu près tous les types d'équipements... Je devrais pourtant le savoir, c'est ce que l'on fait au boulot... quel boulet je suis ! Par contre de mon point de vue Syno est pas très très cool. Je ne met pas en doute tout à fait leurs compétences techniques, mais bon... le dernier message que j'ai eu d'eux c'est quand même de monter mes disques sur un PC sous Windows pour les tester un par un avec les outils constructeurs... et du coup temps que je n'aurais pas fait ça et envoyé un retour, no way ! Tous les utilisateurs de Syno ne sont pas des geek qui mange de la ligne de commande au petit déjeuner ou qui ont un pc ouvert en permanence ! De mon coté, le Syno me rappelle régulièrement qu'il y a 5 paquets en attente de mise à jour... mais comme il n'y a plus de volumes dans le système, et ben ça tourne un peu en rond. Très franchement c'est la première fois que mon Syno est en vrac alors que les données on migrée d'un modèle de Syno à un autre au fil du temps sans le moindre problème, et que toutes les mises à jours que j'ai pu faire ont toujours été de simples "formalités" ! Franchement depuis 5 jours, je suis très déçu par la marque et son manque de soutient sur le sujet. J'espère qu'ils vont se ressaisir un peu...
  9. eraZor

    Mise

    Ok j'avais bien lu ce doc tout à l'heure, mais ce n'est pas très très claire si le fait de réinstaller le système va obligatoirement purger les disques de toutes datas antérieure. Comme j'ai un doute, je ferais bien ce qui est dit ici https://www.synology.com/fr-fr/knowledgebase/faq/579 avant, au moins pour ne pas avoir de regrets... si j'arrivais à récupérer mes films, même si j'ai du boulot après, je n'aurais en définitive rien perdu. Je viens de vérifier : - le disque externe sur lequel le backup journalier se fait contient bien : tous les répertoires et datas utilisateurs, la plupart des répertoires partagés, la musique, les photos et vidéos persos, ainsi que la sauvegarde de la config du Syno. Elle tourne tous les jours à 12h, et celle du 16/12 est OK. - le volume_2 peut monter, donc les sauvegardes TimeMachine je peux les copier sur un autre disque. - me manque juste certains répertoire partagés du volume_1. S'ils veulent bien monter sur un ubuntu, je peu récupérer les datas. Et du coup, je pourrais envisager le double reset, voir + si nécessaire.
  10. eraZor

    Mise

    Bon, le check de md2 semble good : UIEDS1> cat mismatch_cnt 0 le check de md3 est en cours.
  11. eraZor

    Mise

    Peut-être, mais cela consiste en quoi le "double reset" ? Perso, depuis plusieurs année que j'ai un Syno, je n'ai jamais eu à faire ce genre de manip. Je peux trouver ça facilement dans la FAQ ?
  12. eraZor

    Mise

    Oh que oui, plusieurs reboot depuis l'upgrade, et un autre pas plus tard que ce matin. En fait, j'ai remarqué immédiatement après l'upgrade de version, un problème avec le reboot. C'est d'ailleurs ça qui m'a fait détecter le problème : d'habitude le disque remonte sur le réseau au bout de quelques minutes, et tout continue de fonctionner normalement. Mais mardi, cela n'a pas été le cas. D'abord il n'a pas pu redemarrer seul. Ensuite j'ai du le forcer à redemarrer au bouton, et depuis c'est toujours un peu pareil, c'est pas le top pour le redemarrer, même avec la commande propre.
  13. eraZor

    Mise

    Voici le dmesg. http://sendbox.fr/pro/5pa5ttkj63t2/test.txt.html J'ai surement aussi les fichiers plus anciens, je vais les récupérer pour les regarder.
  14. eraZor

    Mise

    Je suis d'accord c'est bien étrange tout ça... est-ce normal que dans /dev je n'ai aucun sda, b, c, etc... ??? Entre avant l'update en 5021 et après l'update, rien n'a changé, je n'ai pas retiré les disques, le seul truc que j'ai fais par sécurité c'est de débrancher le disque USB sur lequel sont les backups les plus importants. Et depuis je ne l'ai pas rebranché. Je ne pense pas que cela puisse jouer ?
  15. eraZor

    Mise

    Ouais, et bien pas très cool tout ça... UIEDS1> smartctl -d sat -T permissive --all /dev/sda smartctl 6.2 (build date Dec 3 2014) [x86_64-linux-3.2.40] (local build) Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sda [sAT] failed: No such device UIEDS1> smartctl -d sat -T permissive --all /dev/sdb smartctl 6.2 (build date Dec 3 2014) [x86_64-linux-3.2.40] (local build) Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sdb [sAT] failed: No such device UIEDS1> smartctl -d sat -T permissive --all /dev/sdc smartctl 6.2 (build date Dec 3 2014) [x86_64-linux-3.2.40] (local build) Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sdc [sAT] failed: No such device UIEDS1> smartctl -d sat -T permissive --all /dev/sdd smartctl 6.2 (build date Dec 3 2014) [x86_64-linux-3.2.40] (local build) Copyright © 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org Smartctl open device: /dev/sdd [sAT] failed: No such device
  16. eraZor

    Mise

    Status du check Raid (que j'ai lancé sur md2 & md3) : UIEDS1> cat /proc/mdstat Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] md3 : active raid5 sdc6[0] sdb6[2] sda6[1] 3906989568 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [uUU] resync=DELAYED md2 : active raid5 sdc5[4] sdb5[3] sda5[5] 3897559296 blocks super 1.2 level 5, 64k chunk, algorithm 2 [3/3] [uUU] [==>..................] check = 10.6% (208308284/1948779648) finish=447.2min speed=64859K/sec md1 : active raid1 sda2[1] sdb2[2] sdc2[0] 2097088 blocks [4/3] [uUU_] md0 : active raid1 sda1[1] sdb1[2] sdc1[0] 2490176 blocks [4/3] [uUU_] unused devices: <none>
  17. eraZor

    Mise

    Je dis Raid 5, c'est ce que retourne le mdstat, et j'avoue qu'avant le DS412, j'avais un DS411 et que j'étais déjà dans ce type de config. Donc j'ai du migrer au plus simple sans trop me poser de questions... Mais vu comme je suis parti, j'ai bien l'impression que je vais pouvoir repartir sur des bases saines et propres d'ici pas longtemps J'ai passer les commandes, voici les résultats : UIEDS1> sfdisk /dev/sdb [/dev/sdb] cannot stat UIEDS1> sfdisk /dev/sdc [/dev/sdc] cannot stat UIEDS1> sfdisk /dev/sdd [/dev/sdd] cannot stat Je demandais si je n'aurais pas carement intêret à tenter un RollBack, même si cela semble risqué, certain s'en sont sortie. Autre idée, de mettre les disque dans un PC, avec un linux live, et voir si le raid monte mieux... J'ai vu sur le site de Syno un truc dans le genre dans les FAQ. Et puis je peux aussi passer chaque disques en revue par un tools constructeur comme me l'a demandé le gars du support, car j'imagine que si je ne lui fait pas de retour, il ne pourra m'aider davantage. Au moins j'aurais passé une étape. Mais ça me gave grave la tout de suite. D'autant que le volume_2 semble monter. Je suis en train de libérer un disque externe pour récupérer mes sauvegardes TimeMachine au cas où ce sera toujours cela de fait. Le check du raid se poursuit. Je suppose que je trouverais le résultat dans un fichier de l'arborescence /sys/.... ?
  18. eraZor

    Mise

    Gaetan, je suis bleufé... tu as presque pu retracer l'historique de mon Syno juste avec les infos que j'ai posté ? En tout cas ton schéma est très explicatif, merci. Pour etre plus précis (cela a peut-etre son importance), lorsque j'ai eu mon DS412+ il était équipé avec 4 disques durs de 2To. Le découpage était comme suit : - 3 X 2To en Raid 5 + 1 X 2To en Hot Spare - 1 volume principal (environ 2To) pour les datas standard + 1 volume secondaire (environ 600Go) pour les sauvegardes Mac TimeMachine - 2 LUN + targets de 64Go pour des tests Windows + Linux - la taille restante n'étant pas affecté pour des besoins futures - en septembre, j'ai changé les 4 disques pour des 4To, le découpage est resté le meme après changement des disques 1 par 1 en jouant avec le hot spare : - 3 X 4To en Raid 5 + 1 X 4To en Hot Spare - volume principal agrandit jusqu'à 3To environ + volume secondaire agrandit jusqu'à 700Go toujours pour TimeMachine - les 2 LUN/Target n'ont pas été modifiées. - idem, la taille restante n'étant pas affectée. Pour la commande sfdisk -l /dev/sda, cela ne semble pas fonctionner : UIEDS1> sfdisk -l /dev/sda [/dev/sda] cannot stat Je vais lancer l'autre commande et ferais un retour. Merci de ton aide en tout cas.
  19. eraZor

    Mise

    Je suis d'accord, mais dans ce cas comment expliquer que sur l'affichage du pvdisplay (ci-dessous), le /dev/md2 est "full", alors que le /dev/md3 ne l'est pas, et que comme par hasard, je n'ai pas de soucis pour monter le volume_2 (même s'il ne monte pas automatiquement au démarrage), que j'ai accès aux fichiers et pas le volume_1 ? J'essayer de trouver une piste tout en montant en compétence... c'est probablement juste de l'ignorance de ma part. Est-ce parce-que le /dev/md2 est le volume_1 par défaut sur tous les Syno ? pvdisplay --- Physical volume --- PV Name /dev/md2 VG Name vg1 PV Size 3.63 TB / not usable 1.69 MB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 951552 Free PE 0 Allocated PE 951552 PV UUID 3LRYsK-gTp6-Mi83-R804-ALL6-U6zw-ASW0WQ --- Physical volume --- PV Name /dev/md3 VG Name vg1 PV Size 3.64 TB / not usable 2.94 MB Allocatable yes PE Size (KByte) 4096 Total PE 953854 Free PE 921339 Allocated PE 32515 PV UUID T0ZrjE-9yoQ-E2P3-9yA6-N922-IWvm-2ZwvBF Quelqu'un aurait une idée sur la signification de la commande suivante ? sfdisk -l /dev/md01 0 4980351 4980352 0 /dev/md11 0 4194175 4194176 0 Error: /dev/zram0: unrecognised disk label get disk fail Error: /dev/zram1: unrecognised disk label get disk fail Error: /dev/md2: unrecognised disk label get disk fail Error: /dev/md3: unrecognised disk label get disk fail /dev/synoboot1 63 32129 32067 0 /dev/synoboot2 32130 224909 192780 0 Je ne suis pas super doué, mais je soupçonne que des erreurs sur 4 ressources c'est pas forcément génial...
  20. eraZor

    Mise

    Je crois que j'ai trouvé quelques chose... la command pcdisplay me retourne ceci (entre autre) : pvdisplay --- Physical volume --- PV Name /dev/md2 VG Name vg1 PV Size 3.63 TB / not usable 1.69 MB Allocatable yes (but full) PE Size (KByte) 4096 Total PE 951552 Free PE 0 Allocated PE 951552 PV UUID 3LRYsK-gTp6-Mi83-R804-ALL6-U6zw-ASW0WQ J'ai lu que /dev/md2 correspond au volume_1 sur un Synology. S'il y a un autre volume, ce sera /dev/md3, etc... Donc de ma lecture, le /dev/md2 semble "full" (c'est ce qui est marqué en gras). C'est étrange, car ce volume est proche de 3To et qu'il n'y avait que la moitié d'occupé avant l'upgrade.
  21. eraZor

    Mise

    Le problème, c'est que dans le "Gestionnaire de Stockage" / "HDD/SDD" il n'y a AUCUN disque visible sur le NAS ! Pas de disque... pas de tests... Je ne vois que des tests à faire en mode commande, car le système lui, voit bien des disques, des partitions, des volumes etc... C'est quand même assez dingue qu'un update soit capable de foutre un b....l pareill !!! Avant l'update tout marchait nickel... 10mn après... plus rien ! Pour moi quelque chose à été mis à jour mais quoi, difficile de trouver, et en plus le support ne semble pas avoir beaucoup d'idées !
  22. eraZor

    Mise

    Voici : UIEDS1> lvdisplay --- Logical volume --- LV Name /dev/vg1/syno_vg_reserved_area VG Name vg1 LV UUID LRlh6W-4wo5-NX2u-zned-l1Tj-R7bq-CVzjBf LV Write Access read/write LV Status available # open 0 LV Size 12.00 MB Current LE 3 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 384 Block device 253:0 --- Logical volume --- LV Name /dev/vg1/volume_1 VG Name vg1 LV UUID bAuY3a-axMj-1lHE-o7AE-X1kA-zJPB-ckJn9d LV Write Access read/write LV Status available # open 1 LV Size 2.93 TB Current LE 768000 Segments 3 Allocation inherit Read ahead sectors auto - currently set to 4096 Block device 253:1 --- Logical volume --- LV Name /dev/vg1/volume_2 VG Name vg1 LV UUID pfbFVM-EIlY-hQAh-LSbu-e6cz-GI3J-XolpMN LV Write Access read/write LV Status available # open 1 LV Size 716.00 GB Current LE 183296 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 4096 Block device 253:2 --- Logical volume --- LV Name /dev/vg1/iscsi_0 VG Name vg1 LV UUID 9qr65H-qGu7-cDiS-sgpb-0G8L-Cwtj-xAlOHz LV Write Access read/write LV Status available # open 0 LV Size 64.00 GB Current LE 16384 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 384 Block device 253:3 --- Logical volume --- LV Name /dev/vg1/iscsi_1 VG Name vg1 LV UUID Dt4Tki-3vdO-a12e-q4u2-V6y2-PlPp-olMH2H LV Write Access read/write LV Status available # open 0 LV Size 64.00 GB Current LE 16384 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 384 Block device 253:4 J'ai comparé avec la précédente liste, cela me semble en tout point identique...
  23. eraZor

    Mise

    Gaetan, j'ai essayé de monter les 2 volumes comme tu me l'as indiqué. Cela fonctionne pour le volume_2, mais pas pour le volume_1 !!! C'est ballot, c'est sur le volume_1 que j'aurais bien voulu aller... Gaetan n'est donc qu'un demi-dieu pour l'instant UIEDS1> mount -o ro /dev/vg1/volume_1 /test1 mount: mounting /dev/vg1/volume_1 on /test1 failed: No such device En recherchant sur google l'erreur que j'obtiens au montage du volume_1, j'ai lu dans des posts que certains préconisent de faire un fsck du Raid pour voir s'il n'y a pas d'erreurs... http://www.cyberciti.biz/faq/synology-complete-fsck-file-system-check-command/ http://forum.synology.com/enu/viewtopic.php?f=7&t=34751 Je ne sais pas trop quoi en penser encore, je me dis que tout n'est peut-être pas perdu puisque j'arrive à me connecter au volume_2 et que je retrouve les datas timemachine que je vais sauvegarder ailleurs. ...Et oui, il y a bien 2 déclaration iSCSI. Les Targets sont visibles dans DMS, mais pas les LUN associées car elles ont sans doute du mal à être montées elles aussi. Mais à la limite c'est pas très grave pour ce point.
  24. eraZor

    Mise

    Merci Tocans, j'essayerais de suivre cette procédure la prochaine fois.... s'il y a une prochaine fois ! Je ne suis pas sur que je ne vais pas devoir tout remettre à blanc... Plus je lis de trucs dans les différents forum, plus je me dis que la "lumière" viens davantage de la communauté que de Synology... Tout fout le camp on dirais !
  25. eraZor

    Mise

    Un petit point sur le sujet, puisque je suis en conversation mail avec le support Synology depuis ce matin de manière active, après les avoirs relancé ! Super, cette "merveilleuse" mise à jour a été retirée du download, cela évitera à d'autres de se retrouver dans une situation inconfortable ! Cependant il reste ceux qui sont en "vrac" et pour lesquels j'ai malheureusement l'impression qu'au cas par cas, l'issue sera "dramatique". Donc pour mon cas personnel, le support à pris la main à distance sur le NAS, a sans doute regardé des trucs (sans que je n'en connaisse le détail), et me propose maintenant, d'analyser chacun de mes 4 disques avec les outils constructeurs, et de leur envoyer les résultats ! Autant dire que je me passerais bien de cette manipulation qui risque d'être fort lourde, consommatrice en temps, et qui à mon avis ne vas déboucher que sur pas grand chose... Je ne suis pas forcement un novice en linux, mais pas un guru non plus, mais je me dis que peut-être quelqu'un sur la communauté aurait une alternative ou une meilleure idée à me proposer que celle du support ? Suite aux messages de Gaetan, j'ai lu un peu de trucs sur LVM et la notion de volumes sur des disques RAID, et sans être devenu un expert, je me dis que c'est peut-être par là qu'il faudrait que je m'oriente plutôt pour sauver ce qui peu l'être encore sur les disques, et puis repartir ensuite en remettant tout à blanc. Qu'en pensez-vous ? Merci de votre retour sur le sujet si vous pouvez.
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.