[RESOLU] Sme8 ne redémarre plus après systemrescueCD

[arnaud056]

Bonjour,
Et bien je n’ai pas beaucoup avancé, même dans ma tête...

Mes recherches ne m’ont pas permis de trouver de piste sur lesquelles je pourrais « accrocher » et approfondir.
L’objectif est cependant clair : « simplement » renommer md126 et md127 en md0 et md1.
Sommes-nous bien d'accord?
Laissons md126 d’abord de côté car il n'a pas l'air de poser problème.

Pour répondre à jdh : sur la machine sur laquelle nous nous penchons « sme_backup », il n’a a effectivement qu’un disque sata de 1TB --> sda.
Les 2 clés usb sdb et sdc ne sont présentes que lorsque je suis en systemrescueCD : l’une est pour l’OS, l’autre pour copier les résultats des commandes pour vous les poster.

Question certainement naïve :
Mes données sont bien présentes:  la racine de sme est sur /dev/sda2 (vu avec sfdisk). Alors pourquoi ne pas :
1.Créer un md1 lié à sda2 : mdadm -AR /dev/md1 /dev/sda2
2.créer un VG « custom » vgcreate custom /dev/md1
3.créer les LV “root” et “swap” avec lvcrerate. De même taille que ce que me renvoie « lvg » actuellement


Pour se faire il faut certainement au préalable libérer sda2 de l’actuel md127. Comme cela :
mdadm --manage /dev/md127 --fail /dev/sda2
mdadm --manage /dev/md127 --remove /dev/sda2

méthodes analogues:
http://askubuntu.com/questions/63980/how-do-i-rename-an-mdadm-raid-array
et
http://serverfault.com/questions/267480/how-do-i-rename-an-mdadm-raid-array

Également essayé: google: sme server md126 md127 n'a rien donné, mis à part ce topic!!


Idée:
j'ai déniché un vieux dd IDE --> je vais installer une sme tout fraiche que je vais casser avec system destr... heu -rescueCD comme je sais si bien le faire. Ce sera alors mon cobbaye pour essayer sans risque d'aggraver mon cas toutes les éventuelles solutions possibles. A commencer par celle de jibe: anaconda (et oui, j'ai perdu les réflexes w$n: réinsérer le cd d'install et ....croiser les doigts).


@+
Arnaud

[Franck78]

c'est pas spécific a SME, normal que google ne retourne rien.
On n'est même pas encore sorti du initrd/initramfs

Selon toute logique, le conf de "md" est embarquée dans ce fichier inirtrd. Donc tout ce que tu feras à l'extérieur ne fera qu'éloigner de la réalité attendue par celui-ci. Tu peux le copier, l'analyser, le modifer, le mettre sur clé usb et adapter en conséquence le ligne initrd=....

On se perd toujours dans ces topics interminables (grub+md+lvm) , voir un jibé ete ses photos. Alors si ton main-root monte d'une façon ou d'un autre, copie le contenu sur un autre système.

Sort ton smartphone et filme les messages affichés par le kernel. Après le 'panic', shift pageup et autres deviennent inexistant.

[arnaud056]

sme 8 ne reconnait apparemment pas les dd IDE.....
En voilà une chance.......

[jdh]

Je suggère de disposer d'un disque identique au disque (sata) d'origine : les 2 feront la paire ensuite pour un raid soft avec 2 disques.
L'intérêt est aussi de protéger le disque existant : les données sont dessus, donc il faut éviter de le manipuler.
D'où l'idée de copier le contenu sur une structure correcte.

[Franck78]

tu sais qu'on ne sait pas vraiment ce qui marche ou pas sur ton système....

http://serverfault.com/questions/267480 ... raid-array

[arnaud056]

Bonjour,
bon, et bien je me suis décidé à appliquer la méthode bête et méchante: nouvelle installation...
- sur la sme de prod avec un seul dd pour l'instant
- récupération du maximum de choses par affa la nuit dernière. Mis à part un message d'erreur incessant sur la sme car "Dav" n'était pas encore installé lorsque affa a rechargé les données: RAS
- pour l'instant j'ai l'impression de ne rien avoir perdu
- 2 choses risquent par contre de ne pas être récupérables: les sauvegardes affa de mes 2 clients qui étaient sur les 2 sme. Je suis en train en ce moment d'essayer de copier les copier sur mon dd usb, mais malheureusement celui-ci n'a que 100gb de libre et si j'ai bonne mémoire les sauvegardes d'affa se concatènent lorsqu'elles sont copiées (ou déplacées à la main). Enfin cette éventuelle perte n'est pas tragique: les clients ne contiennent quasiment aucune donnée (en gros je ne sauvegarde que les profils) et dès que les sme sont de nouveau opérationelles j'effectuerai des nouvelles sauvegarde des clients.
- planning de ce soir: essai des récupération des sauvegardes des clients, effaçage du 2ème dd de la sme de prod, lancement de la synchro raid.

@+
Arnaud

[arnaud056]

bonjour,
ça y est, le jeu est calmé, le chapitre est maintenant quasiment clos:

En résumé, voilà ce que je retiens:
Les points positifs:
- je n'ai perdu aucune donnée. Beaucoup de paramètres et réglages étant apparemment présents dans affa, la réinstallation et la remise en route a été plus rapide et facile que ce à quoi je m'attendais.
- comme souvent rabâché sur ce forum, il est impératif de sauvegarder régulièrement. J'attire l'attention sur le fait qu'à mon avis, une sauvegarde ne suffit pas pour être "en sécurité", mais il en faut plusieurs présentes sur des machines différentes, avec des OS différents: on ne sait jamais à l'avance "comment" ça va planter --> ce qui marchera encore ou pas. La diversité apporte plus de choix pour la stratégie de récupération. Un dd_usb que l'on peut brancher n'importe où apporte aussi beaucoup de flexibilité (important à mon sens quand on est sous systemrescueCD). Je voulais rationaliser le mien --> je compte maintenant m'en acheter un plus gros!
- la resynchro du raid a été enfantine et rapide (-de 2h pour 500gb)
- le gain en expérience....

Les points négatifs:
- un ne faut pas grand chose pour planter une sme! Ça m'a fait penser à un mini-Tchernobyl: tu fais un petit test anodin et tu te retrouves en 1 minute dans une situation que tu ne maitrises plus...
- le raid1 et le lvm ont rendu la chose fortement difficile, à tel point que malgré votre aide je n'ai pu réparer
- beaucoup de stress et de temps perdu. J'imagine l'ambiance au département info si un admin, ou pire, un stagiaire provoque une situation analogue...
- je me suis aperçu que ma sme_backup n'était pas sauvegardée --> il a fallu que je réécrive les jobs et les scripts. J'ai résolu ceci depuis.
- les sauvegardes affa ne peuvent être manipulées que par affa. Une fonction "copie/duplication de sauvegardes", même sous affa m'est inconnue. De ce fait, des sauvegardes affa placées sur une machine plantée ne peuvent être récupérées. Je n'apporte cependant aucune garantie sur la justesse de ces propos: il faut peut être regarder avec rsync pour ceci... Mais un copie/coller classique s'emmêle les pinceaux.

[edit]
maintenant que j'ai "payé" ma bêtise, j'aimerais savoir comment faire pour intervenir avec une systemrescue CD sur une sme sans tout crasher? Comment faites-vous?
Comme ça à chaud, moi je débrancherais un disque afin de pouvoir repartir sur une patte au cas où...
[/edit]

En tous cas merci beaucoup pour votre soutien et pour votre aide. Tout seul je n'aurais pas su par quel côté attaquer la chose.
Merci également à jdh

@+
Arnaud

[jibe]

Salut,

Tout le monde n'est pas de mon avis, et heureusement parce que mes SME sont toutes dans un environnement un peu spécial : TPE, moins de 15 postes (souvent même 5 ou moins), un volume de données réduit (sauf chez moi !) et une évolution très faible ou par grands paliers nécessitant de repenser tout l'ensemble. Et donc dans ce contexte, je considère LVM comme totalement inutile et le désactive systématiquement à l'installation : ça me facilite bien les choses pour la maintenance !

j'aimerais savoir comment faire pour intervenir avec une systemrescue CD sur une sme sans tout crasher? Comment faites-vous?
Comme ça à chaud, moi je débrancherais un disque afin de pouvoir repartir sur une patte au cas où...

Ne travailler que sur un disque peut être un moyen, en tous cas avant toute intervention il faut bien sûr des sauvegardes à jour. Je ne fais jamais d'interventions sur un disque (j'entends, d'interventions "lourdes", risquant une désorganisation du disque) sans en faire préalablement un clone ou une image (dd ou mieux ddrescue est ton ami ).

Après, bien sûr, il faut savoir exactement comment le disque est organisé, s'il fait partie d'un ensemble et lequel. Pour SME, on combine généralement (par défaut à l'install) LVM et raid. Donc, il faut lors d'une intervention, bien en tenir compte et faire les montages nécessaires. Ça fait partie des choses à savoir absolument avant toute intervention ! Au cas où tu ne l'aies pas vu et que tu cherches encore des infos, j'avais mis sur l'ancien forum des liens intéressants vers Raid et LVM. Cherche dans le newbie kit ou dans un fil dont je suis l'auteur où il est question (je suis presque sûr que c'est dans le titre) de LVM.

[arnaud056]

Salut,
oui, sur l'ancien forum tu avais lancé une discussion sur LVM or not LVM. Je l'ai parcourue durant mes recherches pour essayer de me dépanner. Même si je partage tes arguments, ne voulant m'écarter le moins possible d'une config' standard, j'ai laissé le LVM cette fois ci également. Si je galère encore une fois, je reverrais certainement mon choix...

Merci pour le tuyau nommé "ddrescue": j'ai regardé en gros de quoi il s'agit et ça a l'air ...intéressant! En plus c'est sur systemrescueCD. Je vais essayer de copier une petite archive affa avec, pour tester....

Je vais réfléchir à comment m'entrainer à intervenir sur la sme, sans risque de tout casser --> sur une machine virtuelle?????

Merci et @+
Arnaud

[arnaud056]

permettez-moi de déterrer ce topic, non plus pour (encore!) poser une question, mais pour y apporter une réponse.
Il m'est donc encore arrivé la même chose la semaine dernière:
- je souhaite expérimenter quelque chose sur la sme avec lvm et raid1
- je débranche dd#1
- je bidouille et plante la sme sur le dd#2
- je débranche dd#2 et rebranche dd#1
- le boot reste planté au grub (chose que j'aurais dû vérifier avant de bidouiller.........)
- pas grave: j'applique cette méthode avec systemrescueCD
- le grub est opérationnel mais le boot plante un peu plus loin car systemrescueCD a sournoisement changé md1 en md126 et md2 en md127

L'exercice conciste donc à renommer les metadatas:
De nouveau sous systemrescueCD:
J'ai donc appliqué ces instructions:

Code : Tout sélectionner

Stop the array
mdadm -S /dev/md(sysresccd assigned number)

Reassemble the array as correct number for system and write super minor
mdadm -A /dev/md(desired number) -m(sysresccd assigned number) --update=super-minor

et ça fonctionne tout seul pour md126 --> md1

Par contre ça bloque pour md127 car il est actif dans le lvm!
Voici donc la méthode aussi bête que méchante que j'ai appliquée (donnée ici: http://doc.ubuntu-fr.org/lvm)
- brancher un disque annexe de capacité > au disque de la sme
- en faire un volume physique: pvcreate /dev/sd##
- le mettre dans le groupe de volume "main": vgextend main /dev/sd##
- transférer les données de /dev/md127 sur /dev/sd##: pvmove /dev/md127 /dev/sd##
- aller se promener
- sortir /dev/md127 du groupe de volume: vgreduce main /dev/md127

à ce moment md127 n'est plus lié au lvm --> la méthode pour renommer donnée ci-dessus fonctionne alors!
- yapuka remettre /dev/md2 dans le lvm, transférer les données de /dev/sd## sur /dev/md2, sortir /dev/sd## du raid et effacer le volume physique: pvremove /dev/sd##
- par acquis de conscience recharger le grub sur /dev/md1
- la sme repart


Avantages: ça fonctionne (testé pour vous - et pour moi!!) cet après-midi
Inconvénients: il faut un disque annexe et beaucoup de temps: compter 2x(4-5h) de transfert pour ~350gb de données

Cette solution va certainement faire bondir nos cracks mais elle a je trouve, le mérite d'être à la portée de tous et faute de mieux.........

@+
Arnaud qui est très fier de lui cette fois ci...