Bonjour,
 
J'ai utilisé mdadm (et donc pas raidtools) en standard dans Mandriva pour mettre en place un mirroring des partitions systèmes.
Suite probablement à un problème matériel (3 freeze successifs du système), le filesystem "root" s'est retrouvé corrompu et impossible à réparer par fsck.
 
La config étant :
/dev/hda1 + hdc1 = /boot = /dev/md0
/dev/hda5 + hdc5 = swap  = /dev/md1
/dev/hda6 + hdc6 = /       = /dev/md2
 
En bootant sur une distrib' live cd, j'ai recrée par mkfs le filesystem sur /dev/hda6 et hdc6, puis restauré par "restore" le contenu de "root" (restaure successive sur hda6 et hdc6)
(tous les autres FS sont intacts, vérifiés par fsck)  
 
Evidemment, ce serait trop simple, ça ne boote pas.
 
Et même en passant à lilo des options de boot :
 
"linux root=/dev/hda6"  , ou "root=/dev/hdc6"
 
ça ne boote pas plus :
 

 
Que faut il faire de simple pour refaire marcher la config ?

Une idée ?

j'ai bien peur qu'en voulant "réparé" tu aies au contraire tout casser ...
 
Lorsque l'on monte du raid, les partitions utilisées dans le raid ne DOIVENT PLUS être accédées directement, tu ne dois plus t'occuper que de /dev/mdX
 
Tes partitions /dev/hda6 et /dev/hdc6 doivent être de type FD (Linux Raid Autodetect) et donc normalement IMPOSSIBLE de faire un mkfs dessus ...
 
Le mkfs est à faire sur /dev/md2 ...
 
Tu as actuellement ton système ( / ) sur hda6 ?
 
Et au passage un raid de deux partitions swap ne sert à rien, linux le fait de base tout seul ...

Je n'ai rien cassé de plus car de toute façon /dev/md2 (=root) était complètement corrompu.
J'envisage effectivement le fait que toute la config RAID soit à refaire.
Mais la question justement est: comment rattraper le coup sachant que j'ai une sauvegarde du système ?
 
Sur le swap je n'ai pas compris ta remarque. Je l'ai mirroré comme pour un Unix classique. Linux gérerait cela de manière différente ?

Si t'as une sauvegarde ok alors ..
 
* Redémarre sur ton live cd
 
* Préparation des partitions du raid :
Fdisk /dev/hda -> passe la partition hda6 en type fd
Fdisk /dev/hdc -> passe la partition hdc6 en type fd
 
* Création du raid :
mdadm --create /dev/md2 --level=1 /dev/hd[ac]6
 
(Note hd[ac]6 est une forme raccourcie pour /dev/hda6 /dev/hdc6)
 
Là il devrait prendre un peu de temps pour synchroniser ton raid
Tu peux voir où cela en est comme cela :
cat /proc/mdstat
 
* Initialisation du système de fichiers
mkfs.ext3 /dev/md2
 
* Montage de ta future partition root :
mount -t ext3 /dev/md2 /mnt/tmp
 
* Restaure du backup dans /mnt/tmp
 
Reboot et tiens moi au courant ...

Bon, je détaille ce que j'ai fait cet AM:
 
Boot sur Knoppix 5.1
 
su -
 
modprobe md
modprobe raid1
 
MAKEDEV md
 
Pas besoin de passer les partitions en type "fd" (Linux RAID) car elles le sont déjà
 
mdadm --verbose --create /dev/md2 --level=1 --raid-devices=2 /dev/hda6 /dev/hdc6
 
mkfs.ext3 /dev/md2
 
Puis restauration du contenu de "root":
 
mkdir /mnt/md2
cd /mnt/md2
mount /dev/hdd1 /mnt/hdd1
gzip -cd /mnt/hdd1/backup/backup_root.dmp.gz | restore rf -
 
Je vérifie par  
mdadm -D /dev/md2  
que les 2 disques de md2 sont synchros.
 
Je démonte md2 et hdd1, je reboote,
 
et là même problème qu'avant (j'ai passé l'affichage en 50 lignes pour qu'on y voit plus clair) :
 

Bon, le md2 (root) que je viens de reconstruire avec Knoppix, comme décrit ci-dessus, semble corrompu ...
 
Avec madm --examine /dev/hda6 :
 

 
alors que pour hda1/hdc1 (/boot) sur md0, que je n'ai jamais touché et qui à priori n'a jamais été corrompu, j'obtiens :

 
 
 

Poursuite des recherches , je tente, toujours sous Knoppix, de démarrer l'array md2 et monter le FS :
 
Edit de /etc/mdadm/mdadm.conf (en RAM disk)
 
DEVICE /dev/hda6 /dev/hdc6
ARRAY /dev/md2 UUID=<la valeur récupérée avec mdadm --examine ci dessus>
 
mdadm -As /dev/md2
/dev/md2 has been started with 2 drives

-> pas d'erreur donc
 
mount /dev/md2 ... -> OK
 
mdadm -D /dev/md2  
-> Etat de l'Array = clean
-> Etat des 2 partitions = active
-> Aucune erreur
 
umount du FS -> OK
 
Arrêt de l'array :
mdadm -S /dev/md2  
stopped /dev/md2
-> aucune erreur
 
Par contre, maintenant que md2 est arrêté,  
mdadm --examine /dev/hda6  
renvoit toujours, comme sur le snapshot précédent :
Array State: Uu 1 failed
 
Je n'ai pas tenté le reboot je pense que cela ne marchera pas car la situation reste la même.
Je ne sais plus trop quoi faire ...

Rassure moi, entre le  

 
et le

 
tu as bien fait un mount -t ext3 /dev/md2 /mnt/md2 ??

Sous Knoppix que renvoient les commandes suivantes :
cat /proc/mdstat sans démarrer ta pile md2
la même, cat /proc/mdstat mais APRES avoir démarrer ta pile md2
fdisk -l /dev/hda

Euh ... non
 
Je viens de restarter l'array par  
mdadm -As /dev/md2  
puis de faire un  
mount -t ext3 /dev/md2 /mnt/md2
Aucune erreur, et quand je fais un "mount" je vois qu'il est monté en ext3.
Je le démonte puis fais un
fsck.ext3 -f /dev/md2
-> pas d'erreur à priori, echo $? me renvoit 0
 
Il pourrait y avoir un problème ?

bah cet aprem lorsque tu as tout restauré, si tu n'as pas fait de mount entre le mkdir /mnt/md2 et le cd /mnt/md2, tu as tout restauré mais en RAM sous knoppix ...
 
Rien n'a été réellement écrit sur tes disques, donc normal que ton problème soit toujours là ...

Voilà les infos :
 

Non non c'est bon, il y a bien le contenu restauré de root dans /mnt/md2, et le fs md2 est bien monté dessus (vu avec df -k)
C'était un oubli de ma part si j'ai omis des étapes, je fais la navette entre les 2 PC qui ne sont pas au même endroit ...

ok, ça me semble tout correct ...
reste plus qu'à refaire le mount /dev/md2 /mnt/md2 et le restaure dans /mnt/md2 ...

D'ailleurs, j'aurais eu un message d'erreur à la restore car le RAM disk n'aurais jamais pu accepter plus de 4Go de restore alors que la RAM n'est que de 768Mo.

Je viens de mettre à jour le mdadm.conf sur le FS de md2, puisque comme  l'array avait été reconstruit l'UUID n'était plus le même, puis umount et stop array, puis reboot -> toujours les mêmes erreurs au boot.

Je vais aller manger, et puis ensuite je vais essayer sous Knoppix de démarrer les array md0 (/boot) et md1 (swap), pour voir si c'est OK.
C'est ma dernière piste sérieuse, après je suis sec.

Bon après pas mal de comparaisons et de recherches, je crois avoir compris ce qui ne vas pas.
L'array md2 que j'ai recréé avec Knoppix possède un superblock de version 01.00.03 (visible par mdadm --detail)
Les autres array, md0 et md1, créés lors de l'installation Mandriva, possèdent un superblock de version 00.90.03.
 
Effectivement d'après la man page de mdadm, on voit que 2 types de superblock sont dispos :
 

Normalement le mdadm de Knoppix aurait du installer par défaut un supertblock v0.90, mais il a installé un superblock 1.0.
 
Je vais recréer demain l'array md2 en forçant la version 0.9 du superblock et j'espère que cette fois-ci ça va marcher.

Bien vu cette histoire de version du superblock ...
J'aurai appris qqchose, je ne savais pas qu'il pouvait y avoir ce problème ...
 
Parce que le problème de base c'est cette ligne :
mdadm: cannot find devices for array md2
 
Ce qui veut dire, que si avec la bonne version du superblock ça marche, le stockage des devices d'une pile dans le superblock aurait changer d'une version de superblock à l'autre ? si c'est ça, c'est super con, vive la retro-compatibilité ...

Bon, même en changeant la version de superblock c'était toujours pareil.
 
Et puis j'ai un peu réflêchi et je me suis dit: comment, au boot, le noyau sait il qu'il doit utiliser tel ou tel array ? il est précisé /dev/md2 dans lilo.conf, mais md2 ne correspond pas à un endroit particulier du disque, comme hdxn ou sdxn.
Donc le noyau doit forcément utiliser l'UUID pour trouver l'array de "root".
Le problème, c'est que lorsque j'ai recrée l'array qui était corrompu, l'UUID a changé.
 
Donc je récupère dans le /etc/mdadm.conf (restauré) l'UUID de l'ancien array "root", et je passe sous Knoppix la commande suivante :

Et là, après mdadm -S /dev/md2 (arrêt de l'array), reboot et ... ça boote !
 
Une autre solution aurait été d'inscrire quelque part le nouvel UUID de l'array root à la place de l'ancien, mais je n'ai pas trouvé où ... pourtant ça doit bien se trouver quelque part.

l'UUID est écrit dans le superblock, superblocks qui sont écrits au début des partitions fd ...

Oui, mais je parlais de changer l'UUID non pas dans la partition (ce que j'ai finalement fait), mais à l'endroit où c'est référencé pour le noyau au boot.
Car comme je disais le noyau ne peut pas reconnaître par magie que /dev/md2 est a tel ou tel endroit.

en fait je pense qu'à la place de mon "mdadm --assemble --update=uuid ...", j'aurais pu faire depuis Knoppix un "lilo -r /mnt/md2", et l'UUID de md2 aurait été inscrit où il faut pour qu'au boot le noyau utilise md2 comme "root".

Bah si on cause technique, il y a deux trucs ...
 
D'une part lilo qui a comme spécificité (après c'est soit un avantage, soit un inconvénient) de pointer le noyau sur lequel il faut booter et la partition root directement par leurs adresses physiques (disque identifié par son code bios, et le fichier noyau par son adresse sur le disque)
 
Après pour ce qui est de l'assemblage des piles, mdadm est par défaut configuré pour tout détecter automatiquement au démarrage. Comment il fait ? il cherche toutes les partitions de type fd sur la machine et les assemble en comparant leur superblocks (qui contenant l'uuid de la pile d'appartenance, le niveau du raid [0,1,5...], l'ordre du disque dans la pile)

Oui mais le noyau doit récupérer l'info que "root" correspond à telle ou telle UUID, car même en faisant un scan, il va trouver plusieurs array qu'il peut assembler, mais jamais il ne pourra savoir lequel contient le FS "root".

c'est lilo qui fait ce travail ...
et le noyau est lancé avec l'option root=/dev/md2
mdadm s'étant chargé d'assembler /dev/md2 avant tout accès du noyau dessus ...

L'UUID doit être dans le MBR, c'est la seule solution pour pouvoir identifier la partition "root".
Pareil probablement pour la partition "/boot" (mais comme chez moi elle n'avait pas été vérolée, ça n'a pas posé de pb car l'UUID est resté le même)

tu me lis de travers !!!!
 
l'UUID le noyau s'en CONTRE FOUT, du moins pour le boot ...
seul le driver raid et mdadm s'en occupe pour trouver tous les devices qui correspondent à l'array qui se cachent derrière cette UUID.
 
Pour ce qui est du boot, il n'y a rien dans le MBR, le MBR (512 octets) ne contient qu'un 1er bout de lilo (celui qui affiche LI) permettant d'aller chercher sur le disque le 2ème bout (qui affiche le LO puis le menu)
Quant aux informations sur les noyaux bootables, elles sont il me semble dans le fichier /boot/map créé par lilo lorsque l'on le relance.
 
Une fois que tu as choisi ton noyau, lilo lit ce fichier map pour savoir à quelle adresse disque passer la main (l'adresse du 1er octet de ton fichier noyau binaire)
 
Le noyau connait ensuite la partition root QUE et UNIQUEMENT par la directive root=... qui lui est passée par lilo

Oui tu as raison ce n'est pas dans le MBR.
Mais ce n'est pas non plus dans le fichier map.
En fait, c'est dans le fichier initrd :
 
Après avoir recopié le "initrd" de /boot en le renommant en ".gz" (car il est compressé)

Il y a bien le UUID de mon "root" à l'intérieur.
 
Cette fois je crois que tout est expliqué, ça me travaillait un peu cette histoire car j'aime bien connaître la fin du film  

Hello,
 
tu as du générer un nouvel initrd finalement pour que ca marche?
 
Moi j'ai une debian etch avec 4 dd en raid1 deux à deux.
 
Pour mon 1er raid1, j'ai:
/dev/md0 -> swap
/dev/md1 -> /boot
/dev/md2 -> PV en LVM contenant
                 1 Volum Group qui vient des LVS, et parmis ces LVS, j'ai un LV Slash qui est monté en /
 
/dev/md3 -> PV en lvm qui stocke des donnéees
 
Recemment justement, j'ai voulu passer ma / d'un LV qui etait en ext3 à un LV qui était en reiserfs.
 
- J'ai booté sur un livecd.
- Sauvegardé le contenu de mon LV Slash
-Renommer SLash en SlashOld
- Creer un LV SLash
- Restaurer le contenu de ma / dans ce LV SLash
 
Mais justement après pour que ca marche bien, j'ai du me creer un nouvel initrd.
 
Donc par curiosité, je voulais savoir si sous mandriva, ca marche pareil et que tu as donc du te créer un nouvel initrd?
 
Merci :-)