Reprise du message précédent :
Essaye
 
chroot /mnt/md0 mkinitrd -o /mnt/md0/boot/initrd.img-2.6.8-2-386 /lib/modules/2.6.8-2-386
 
où /lib/modules/2.6.8-2-386 est le chemin des modules pour la version sur md0

chroot /mnt/md0 mkinitrd -o /mnt/md0/boot/initrd.img-2.6.8-2-386 /lib/modules/2.6.8-2-386
/usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
FATAL: Module ext2 not found.
WARNING: This failure MAY indicate that your kernel will not boot!
but it can also be triggered by needed modules being compiled into
the kernel.
mkcramfs: open failed: /mnt/md0/boot/initrd.img-2.6.8-2-386: No such file or directory
 
:-(

stat /mnt/md0/boot/initrd.img-2.6.8-2-386 :
Modify: 2005-12-21 20:49:40.000000000 +0100
 
Il a pas été modifié apparemment

chroot /mnt/md0 mkinitrd -o /mnt/md0/boot/initrd.img-2.6.8-2-386 /lib/modules/2.6.8-2-386
/usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
FATAL: Module ext2 not found.
WARNING: This failure MAY indicate that your kernel will not boot!
but it can also be triggered by needed modules being compiled into
the kernel.
mkcramfs: open failed: /mnt/md0/boot/initrd.img-2.6.8-2-386: No such file or directory
 
:-(

Désolé le chroot que j'ai donné est pas le bon, voilà le bon:
 
chroot /mnt/md0 mkinitrd -o /boot/initrd.img-2.6.8-2-386 /lib/modules/2.6.8-2-386
 
Mais ça ne va pas résoudre le problème de "add_modules_dep_2_5: modprobe failed"
Essaye quand même mais ça va dépasser mes compétences car je n'ai jamais regénéré le initrd.
Par contre il doit y avoir pas mal d'aide sur le net.

chroot /mnt/md0 mkinitrd -o /mnt/md0/boot/initrd.img-2.6.8-2-386 /mnt/md0/lib/modules/2.6.8-2-386
/usr/sbin/mkinitrd: /mnt/md0/lib/modules/2.6.8-2-386 is not a valid kernel version
 
Bon  
cd /mnt/md0
chroot `pwd`
mkinitrd -o /boot/initrd.img-2.6.8-2-386 /lib/modules/2.6.8-2-386/
 
/usr/sbin/mkinitrd: add_modules_dep_2_5: modprobe failed
FATAL: Module ext2 not found.
WARNING: This failure MAY indicate that your kernel will not boot!
but it can also be triggered by needed modules being compiled into
the kernel.
 
stat /boot/initrd.img-2.6.8-2-386
Modify: 2007-02-01 15:08:42.000000000 +0100
 
J'essaie un reboot ?

J'ai l'impression que c'est le ext2 qu'il n'aime pas.
Si tu n'as aucun FS en ext2, tu peux essayer en le supprimant de initrd/modules ...

Oui c'est ce que je ênsais faire ;-)
 
mkinitrd -o /boot/initrd.img-2.6.8-2-386 /lib/modules/2.6.8-2-386/
 
Pas d'erreur.
Je reboote ou je relance lilo avant ?

Très honnêtement j'en sais rien ...
C'est peut être inutile vu que l'on conserve le même nom de fichier, mais je dirais que ça peut pas faire de mal ...

Bon g relancé lilo:
Warning: '/proc/partitions' does not match '/dev' directory structure.
    Name change: '/dev/cloop0' -> '/tmp/dev.0'
Warning: '/dev' directory structure is incomplete; device (240, 0) is missing.
Added Linux *
Skipping /vmlinuz.old
The boot record of  /dev/md0  has been updated.
The boot record of  /dev/hda  has been updated.
Warning: /dev/hdc is not on the first disk
The boot record of  /dev/hdc  has been updated.
 
Je rebooooooooooooooooote !

ca maaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarche !
Trop fort, merci !!!!!!!!!!!!!!!!!!!!
Si j'ai bien tout compris, on a reconstruit l'initrd après y avoir ajouté des  modules dans sa conf.
A quoi çà sert cet initrd ?

Voilà une bonne définition que j'ai trouvé (désolé si c'est en anglais) http://www-128.ibm.com/developerwo [...] linuxboot/

Le principe est de coller dedans tous les drivers dont on a besoin pour accéder au root filesystem, en l'occurence ici ext3 et md+raid1.
Ca reviendrait au même de les inclure dans le noyau mais le problème c'est que régénérer un noyau c'est très lourd.  

Ah ok je comprends.
Donc maintenant, si je crashe un disque dur, suffit que je le change, que je reboote sur knoppix et que je refasse la manip  
mdadm --assemble /dev/md0 /dev/hda1 /dev/hda2
et ca suffit ?
Et si un des disques crashe, est-ce que je peux booter sur celui qui reste sans problème ?
 

Je répondrai ce soir.

Encore une toute petite question et je me tais
Je me dis que plutot que d'utiliser le reste de mes dd 160Gigo pour mettre en raid les /home, je réserverais bien une petite place sur une nouvelle partition /hda5 et /hdc5 pour installer une debian testing (en raid aussi).
Le souci, c'est que si je fais un cfdisk et que je modifie  
/hda3 puis /hdc3 (destinés à recevoir plus tard les /home en raid) pour les redimensionner, çà va forcément modifier les tables des partitions des disques hda/hdc montés en raid hda1/hdc1 sous /dev/md0.
1/ Est-ce ce que çà ne risque pas de foutre en l'air le raid md0 ?
2/ Si c'est faisable, faut-il utiliser pour celà un live cd afin que le raid hda1/hdc1 ne soit pas lancé, puis l'assembler à nouveau en live cd ?

Pour revenir sur ce qui a été fait cet AM, on a reconstruit l'initrd, non pas pour ajouter les modules md/raid1/ext3 (qui je pense étaient déjà dedans), mais pour ajouter le ROOT=/dev/md0.  
Il a été nécessaire de renseigner /etc/mkinitrd/modules qui était vide, mais c'est normal car en général l'installer de la distrib' ne met pas en cohérence ce qu'il installe (kernel,initrd), avec les fichiers de config.
 

La procédure c'est, pour chacune des partitions du disque HS :
mdadm --set-faulty /dev/md0 /dev/hda1
mdadm --remove /dev/md0 /dev/hda1
Ensuite après remplacement reconstruire le miroir par :
mdadm --add /dev/md0 /dev/hda1
 

Oui, et c'est conseillé d'essayer (en débranchant le disque pour simuler la panne)

J'ai pas tout compris.
Tu as root ( / ) sous hdx1, swap sous hdx2, /home sous hdx3 c'est ça ?
Et tu veux redimensionner /home ?

Oui c'est çà:
J'ai actuellement root / sous hda1/hdc1 (md0)
Swap sous hda3/hdc3
Mon disque est partionné en hda1/hda2/hda3 (idem pour hdc)
 
hda2/hdc2 était destiné à recevoir /home sous md1
Cependant je voudrais, avant de restaurer le /home, redimensionner (réduire) hda2/hdc2, puis recréer hda3/hdc3 et hda5/hdc5 (pour migrer la swap en hda5/hdc5).
L'espace créé en hda3/hdc3 me servira a mettre un autre système (debian testing) qui pointera également vers le /home en hda2/hdc2, et utilisera la swap commune en hda5/hdc5.
La question que je me pose, c'est:
est-ce que je peux sans risque repartitionner le disque (sauf à toucher à hda1/hdc1 bien sur) avec cfdisk, sans craindre de détruire le raid ?

Oui en bootant sur un live CD et tant qu'on ne touche pas aux partitions de l'array, aucun problème pour redimensionner les partitions home et swap.  

Bon eh bien j'ai réinstallé le /home en raid après avoir redimensionné les partitions /home et /swap, et j'en ai créé une nouvelle; tout fonctionne à merveille.
Je suppose qu'une fois installé le système Testing en raid sur la nouvelle partition, celle-ci pointant vers les mêmes /home (donc le même raid), je devrai faire un simple "mdadm --assemble" dessus.
 
Merci beaucoup pour le temps que tu as consacré à toutes ces explications, je vais essayer de faire une synthèse.
 
Thierry

Normalement en renseignant sur le second système le mdadm.conf avec le bon UUID pour /home en RAID, ça devrait démarrer tout seul.
 

Tu me dis qu'il est conseillé d'essayer (en débranchant le disque pour simuler la panne) de booter sur un seul disque pour simuler une panne.
Si j'écris sur le disque restant seul pendant le test, le second se synchronisera-t-il tout seul une fois rebranché et redémarré ?
Ou bien, lorsque je l'aurai fait le test, je devrai, au redémarrage avec les 2 disques, suivre la procédure:
mdadm --set-faulty /dev/md0 /dev/hda1
mdadm --remove /dev/md0 /dev/hda1
Ensuite après remplacement reconstruire le miroir par :
mdadm --add /dev/md0 /dev/hda1  
?

Suite à un crash du raid (pb bios), j'ai fait un simple mdadm --add /dev/md0 /dev/hdc1 et tout est rentré dans l'ordre.
 
J'ai installé une Etch (testing) sur une partition libérée (hda5) type Linux (et non fd), mais je ne parviens pas à booter dessus.
 
    hda1        Boot        Primary   Linux raid autodetect         20003,89
    hda2                    Primary   Linux raid autodetect           119998,61
    hda3                    Primary   Linux swap / Solaris             1998,75
    hda5        Boot        Logical   Linux ext3       [/]             22693,55
 
J'ai modifié Lilo en hda1 pour spécifier :
delay=1000
other=/dev/hda5
         label=etch
 
Au démarrage, j'ai donc bien le choix entre le système en raid sur hda1 et la etch sur hda5, mais si je choisis la etch, je reviens inévitablement sur le sytème en raid.
Pourtant, un autre lilo en hda5 a bien été créé !
 
:-|