gaetan.cambier

Utilise synomount a la place, je sais pas exactement la différence mais si synology a créé sa commande, il doit y avoir une raison

Le temps, je sais pas ça dépend de plein de paramètres Tu peux essayer le resize après

fais ce qu'il te dis viens de penser à un truc très con ... je crois savoir pourquoi il veux verifier le filesystem : tu as fais ta commande dd sur un disque en utilisation, je crois que c'est de la que vienne les problèmes :s

en fait, non, car c'est des disque clone et les identifiant du raid sont les meme, j'avais resolu le problème du montage ici : mais pour cela, il faut un 2° disque dans le nas, pour avoir la partition systeme et swap en raid, puis ejection --> reinsertion du nouveau disque et alors les commande fonctionne

bon, en fait le problème est "simple" faut ideallement savoir faire le umount, le problème, c'est que le nas boot et charge toujours les service qui sont stocké sur le volume :s je trouve pas de solution pour demonter proprement la partition, il doit surement avoir une commande spéciale sur le syno, mais je trouve pas :s

c'est bizarre, et relancer le resize en ligne de commande : resize2fs /dev/md2 mais je crois que l'on va avoir le meme resultat faudrait faire le resize offline, mais faut demonter le système de fichier, ce qui est difficile vu que ton volume1 est utiler :s on peux toujours essayer ceci : umount -l /volume1 resize2fs /dev/md2 il est possible que le nas se mette à sonner à la commande umount, c pas grave

bon, c'etait bien la commande resize2fs /dev/md2 par contre la permission refuséee, c'est pas normal, tu est bien en root pour ta connection ssh ? edit : viens de tester e admin, la permission refusée arrive plutot, bon, reboot, et test par l'interface graphique

oui, suis con ... resize2fs /volume1

essaye ceci : resize2fs /dev/md2 un nas syno, c'est un linux, il y a peu de raison de faire un reboot, la seule raison en general, c'est le changement de kernel ou des modification materielle

ok, logique que ca ne retourne rien bon, faut juste agrandir le système de fichier alors a mon avis, notre amis dsm sera ok pour le faire maintenant, tu peux tester

ok, en fait, c'est logique, je suppose que tu est en shr --> faut modifier le lvm avant de modifier, j'aurait besoin des commandes suivantes : pvdisplay vgdisplay lvdisplay

Pas besoin de reboot, je rentre chez moi dans 10 minutes pour la suite

donc, ici, les taille sont en octect dans les 2 commandes, et ca fait encorin 2 to --> pas bon on change la taille de la partition 5 à la main : echo 3902297440 > dev-sda3/size tu relance la commande précedente pour avoir confirmation du changement : grep . dev-sd*/size si c'est ok, tu agrandis le raid : mdadm --grow /dev/md2 --size=max et tu peux verifier le resultat avec cat /proc/mdstat

bon, donc, c'est un problème de rais, je l'avais deja resolu une fois, mais difficilement, on va essayé de faire simple : tu peux me donner ceci : cd /sys/block/md2/md cat component_size grep . dev-sd*/size

me suis trompé à la taille de la partition : 8 3 3902297440 sda3 c'est en secteur de 512 --> enriron 2to, c'est la que cela coince. j'aurait besoin de ceci : sfdisk -l /dev/sda

pour info, la prochaine version de cloudstation risque de faire econimiser le la place (enfin, il y aura + de paramètrage pour le versionning apparemment)

si je suppose bien, tu as d'abord remplacer le disque avant de lancer les commande ? (pour etre sur) donc, ton nouveau disque se trouve maintenant dans a baie 1 (sda) tu as essayé betement maintenant de l'agradir via le dsm (on peux toujours espérer que cela fonctionne) si pas, je voit que la taille de la partition est ok --> plus rien à faire par contre, le raid à une taille de 2TO --> faudra commencer par là je te donne deja la commande si jamais l'interface graphique n'est pas gentille mdadm --grow /dev/md2 --size=max ensuite, tu verifie le resultat avec cat /proc/mdstat

je doit partir la matinée, mais donne moi deja les info suivante : cat /proc/mdstat je pense aussi à une chose : tu as copier le disque 1 --> 2, le mieux serait d'eteindre le syno, enlever l'ancien disque, mettre le nouveau à la place de 'ancien, et essayer ainsi normalement, il devrait retrouver volume copié et se rendre compte de rien

programme construction (desolé pour la faute de frappe), c'est le programme fournit par seagates pour verifié le disque badblocks : c'est la commande en ssh pour vérifier le disque directement de son nas

c'est ca, mais normalement, vaut mieux s'assurer que le disque est bien ok avant avec une ecriture de 0 avec le programme constructeur ou un badblocks

il faut lire tous le message, dsm te note surement que tu va perdre toutes les donnée du nouveau disque inséré (si c'est un disque vide, c'est pas grave) c'est pour eviter des perte de donnée pour des personne qui utiliserai un disque contenant deja des données

lance cette commande en ssh, tu saura d'ou viens le problème : du -hs /volume1/*

dd ne changera pas le système de partition, c'est meme logique vu que c'est une copie octect à octect, et la partition de trouve au debut du disque après pour etendre, si je suis arrivé à etendre un raid en ligne de commande, on y arrivera pour toi aussi

en fait, avec la commande dd, tu va te retrouver avec un sda3 de - de 2to, et faudra l'agrandir après l'autre solution, des de "betement" copier les données, mais la, pour renammer ton volume2, vaut pas connaitre linux (enfin un peu) faut surtout savoir ou syno à planqué la fonction pour renommer un volume (et c'est pas betement)un fstab, de qui est dommage)

et les repertoire sont-ils bien indexé ? autrement, c'est plutot normal qu'il soit vide ...