Jump to content
XPEnology Community

Migration a 2h du mat ! aie aie aie


Recommended Posts

Bonjour,

J'ai un xpenology baremetal sur une CM ASRock 90-MXGYM0-A0UAYZ qui était en loader 1.02b sur la 6.1.7 depuis un bon moment.

(J'ai aussi un carte sata dessus avec une sata map paramétrée en 242)

J'ai eu des problèmes avec certains paquets qui ont motivés une migration hier soir pensant être en loader 1.03b

Quelle erreur !

Rien ne marche au reboot. Je comprends mon erreur en montant la partition de l’ancienne clef usb et en relisant le gurb.cfg

J'ai donc tester une migration en loader 1.04b, ça ne marche pas et foire avec différente erreur.

Puis j'ai testé une migration en loader 1.03b (DS3617xs) qui semble avoir fonctionné.

Cependant mon code de facteur d'authentification double ne marche pas, aucun e-mail n'est envoyé en récupération sur aucun de mes comptes, ssh était(et reste) désactivé et je ne vois aucun moyen de me connecter depuis l'écran du NAS.

Mon erreur est elle fatale ou une âme charitable connaît une solution pour me sauver de ma hâte stupide ?

Link to comment
Share on other sites

Bonjour,

En principe, si aucune action de formatage n'a été faite durant la migration, les données sont toujours accessibles et intactes au niveau disque.

Maintenant, revenir à une version plus ancienne est un procédé déjà décrit dans le forum mais nécessite (de mémoire) de modifier la valeur de la version dans un fichier. On en revient à un accès au NAS.

Je te conseille d'attendre la réponse d'autres personnes plus au fait que moi de ces procédures, mais pour récupérer un accès SSH (et modifier le fichier), il me parait possible de booter sur une clef contenant un Linux (SystemRescueCD est un outil que j'aime beaucoup car à peu près tout ce dont on peut avoir besoin dans ce genre de cas est directement présent au boot), de rechercher le raid et de le monter (voir le site de Synology pour la procédure de récupération des données). Pour le DSM, il est installé dans /dev/md0 ce qui dans le cas d'une réparation sera probablement /dev/md127 car le raid n'est pas configuré pour cette machine.

Ensuite, réactiver le SSH devrait pouvoir se faire en éditant le fichier /etc.defaults/synoinfo.conf et modifier la valeur de supportssh à "yes".

root@Maison:/etc.defaults# grep ssh /etc.defaults/synoinfo.conf
supportssh="yes"

Maintenant, reste le problème de l'authentification en espérant que les mots de passes sont restés intacts. Sinon, il faudra réitérer la procédure de boot pour installer des clefs de chiffrement permettant une authentification directe (et modifier le fichier /etc/ssh/sshd_config - et probablement aussi celui dans /etc.defaults/ssh - pour valider la connexion de root et les clefs).

 

Pas d'autres pistes pour le moment, mais je ne peux que déconseiller les migrations à 2h du matin, pour avoir migré plus d'une centaine de système la nuit, il vaut mieux commencer plus tôt et se faire surveiller par quelqu'un passé une certaine heure... les erreurs sont trop faciles avec la fatigue.

 

Jacques

  • Thanks 1
Link to comment
Share on other sites

Merci pour la réponse.

La piste SystemRescueCD semble pas intéressante.

Est ce gênant si le raid est un SHR (raison historique alors que tout mes disques sont identique depuis des années maintenant) ?

Agir sur l'option ssh ou mieux le double facteur implique t'il forcément de monter ce raid ? (question peu être au reste de la possible l'audience)

 

Link to comment
Share on other sites

Le raid SHR est une combinaison de raid logiciel (périphériques /dev/mdX) et de LVM (gestion de volumes logiques).

Le LVM permet d'accroître dynamiquement la taille d'un disque (et optimise donc l'usage de ceux-ci en minimisant la place perdue) et le Raid permet d'assurer la redondance des données au niveau inférieur pour la sécurité. Donc ça ne pose aucun problème de fonctionnement, puisque DSM 6 le gère sans soucis, mais ça complique un peu l'accès aux données si le volume est réparti sur plusieurs disques.

Pour pouvoir accéder aux données depuis un système externe, il faut monter le raid et éventuellement le volume (le DSM par exemple est éclaté en raid sur tous les disques mais n'utilise pas de LVM) pour accéder aux données (en principe en SHR, le LVM est systématique pour les volumes DATA créés avec de la redondance).

Pour changer un paramètre (et donc modifier le contenu d'un fichier de configuration), il faut pouvoir accéder aux données du DSM, donc monter le raid (le premier trouvé en principe) en accédant depuis un autre système d'exploitation.

Autre possibilité, installer un seul disque dans un PC capable de lire et écrire sur le système de fichiers utilisé pour le DSM (en principe ext4, ce qui implique un OS Linux ou un drivers spécifique sous Windows) et modifier les fichiers, puis n'utiliser que ce disque pour redémarrer le NAS (le volume de DATA passera en faute, mais si on ne formate rien lors de la réinstallation du DSM, on le retrouvera en remettant tous les disques une fois l'installation terminée et le DSM réparé.

Dernière option possible que je vois, réinstaller tout le DSM et restaurer ensuite une sauvegarde de la configuration précédente (puis adapter les options qui ne sont pas sauvegardées et il peut y en avoir pas mal).

 

Attends confirmation d'autres personnes sur ce forum pour la marche à suivre et tiens nous au courant de la méthode utilisée et du résultat.

 

Jacques

  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...