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.gz
If 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-k7
qui indique de faire un chroot lorsque l'on installe un initrd pour un
autre endroit...
L'initrd ne dépend pas vraiment du kernel en cours d'exécution avec/sans devfs : je suis en 2.6 et donc SANS devfs et il en a créé un quand m^eme. Mais l'initrd est créé lors de l'installation du noyau et pas lors de sa création en fonction des différents paramètres de mkinitrd *au moment de l'install*
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
Jean-Luc
pgpaCsV3b1VBZ.pgp
Description: PGP signature