Jean-Yves LENHOF a écrit :
Pour les archives: il a été *impossible* de booter le serveur en RAID1 en utilisant l'initrd, avec ou sans devfs. J'ai monte l'initrd pour voir ce qu'il y avait dedans, même sans devfs dans le noyau il y faisait référence! En fait, l'initrd semble _largement_ dépendre du kernel en cours d' exécution (celui-ci était effectivement en devfs).Le lundi 28 mars 2005 à 19:49 +0200, Jean-Yves LENHOF a écrit :Le lundi 28 mars 2005 à 19:22 +0200, daniel huhardeaux a écrit :Jean-Yves LENHOF a écrit :<snip>Il y a notamment une ligne qui attire mon regard : mkinitrd -r /dev/md0 -o /boot/initrd.img-2.4.22raid Et donc le -r pourrait être la solution ?Dans le même genre d'idée il y a le document /usr/share/doc/initrd-tools/NEWS.Debian.gzIf you are creating an initrd image for an alternative root directory, you should run mkinitrd under chroot, e.g., chroot /newroot mkinitrd -o /boot/initrd.img-2.6.5-1-k7 2.6.5-1-k7qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
J'ai supprimé l'initrd et mis en dur les options nécessaires, la machine est partie du premier coup.
Voici les derniers logs: mount: mount.dev does not exist pivo_root: no such file or directory /sbin/init: 431 can't open /dev/console no such file kernel panic attempt to kill init Merci à Jean Yves et Jean Luc pour leur aide. -- Daniel Huhardeaux ______ _____ _____ ______ ______ __ enum +48 32 285 5276 /_ _// _ // _ //_ _// __ // / IAX FWD +1 7009 422493 / / / // // // / / / / /_/ // / sip:101 h323:121 @voip./_/ /____//____/ /_/ /_/ /_//_/.com