si je veux booter sur un kernel 2.4.27 minimal d'une Debian testing en
supprimant l'initrd pour un boot en Raid1/ext3, voila ce que je fais
comme modification dans le .config d'origine:
1. supprimer la prise en charge de l'initrd
2. en dur ext3
3. en dur MD + Raid1
4. en dur IDE et BLK_DEV _IDE
Ai je oublié quelquechose?
Mon probleme est que j'ai un serveur auquel *je n'ai pas accès*, avec 2
disques durs. La machine a été installée en SARGE kernel 2.4.26,
upgradée en 2.4.27, sur hda, 3 partitions / , /home et swap et démarre
sans problème.
J'essaye vainement de redémarrer cette machine en Raid ayant préparé et
installé ce qui va bien sur hdc (/boot = /dev/md0 et /=/dev/md1 et
swap), mais rien à faire: aux dires d'un technicien devant l'écran,
j'aurai une erreur can't open /dev/console puis un kernel panic. Bien
entendu, lorsque je monte les partitions Raid après avoir rebooté sur
hda, tout est ok.
Je veux donc tester sans l'initrd, je pense que c'est lui qui créé le
problème.
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
A+
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
daniel huhardeaux
Jean-Yves LENHOF a écrit :
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 ?
Je ne pense pas puisque j'ai modifié le fichier mkinitrd.conf en precisant ROOT="/dev/md1 ext3" L'option -r ne fait que remplacer cette valeur. Extrait du man:
[...]
-r root This option overrides the setting of ROOT in mkinitrd.conf.
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.,
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
Ca devient compliqué: le /newroot c'est le / donc mon /dev/md1. Mais le /boot/initrd.img-<kernel-version>, c'est donc /newboot/initrd.img-<kernel.version> puisque ma partition /boot est /dev/md0
Je crois que je vais me passer du initrd, c'est plus simple!
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Yves LENHOF a écrit :
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 ?
Je ne pense pas puisque j'ai modifié le fichier mkinitrd.conf en
precisant ROOT="/dev/md1 ext3"
L'option -r ne fait que remplacer cette valeur. Extrait du man:
[...]
-r root
This option overrides the setting of ROOT in mkinitrd.conf.
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.,
qui indique de faire un chroot lorsque l'on installe un initrd pour un
autre endroit...
Ca devient compliqué: le /newroot c'est le / donc mon /dev/md1. Mais le
/boot/initrd.img-<kernel-version>, c'est donc
/newboot/initrd.img-<kernel.version> puisque ma partition /boot est /dev/md0
Je crois que je vais me passer du initrd, c'est plus simple!
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 ?
Je ne pense pas puisque j'ai modifié le fichier mkinitrd.conf en precisant ROOT="/dev/md1 ext3" L'option -r ne fait que remplacer cette valeur. Extrait du man:
[...]
-r root This option overrides the setting of ROOT in mkinitrd.conf.
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.,
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
Ca devient compliqué: le /newroot c'est le / donc mon /dev/md1. Mais le /boot/initrd.img-<kernel-version>, c'est donc /newboot/initrd.img-<kernel.version> puisque ma partition /boot est /dev/md0
Je crois que je vais me passer du initrd, c'est plus simple!
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
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).
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
qui indique de faire un chroot lorsque l'on installe un initrd pour un
autre endroit...
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).
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
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
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).
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
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
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).
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
qui indique de faire un chroot lorsque l'on installe un initrd pour
un
autre endroit...
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).
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
qui indique de faire un chroot lorsque l'on installe un initrd pour un autre endroit...
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).
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
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
daniel huhardeaux
Jean-Luc Coulon (f5ibh) a écrit :
[...] 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*
Hmmh:
Dans script de l'initrd:
ROOT=/dev/md1 [...] mdadm -A /devfs/md/1 -R -u [...] /dev/hdc6
Le kernel compilé qui est lié à ce initrd est compilé avec devfs, j'ai créé l'initrd avec -r /dev/md1 Comment au démarrage, la machine doit trouver ses petits entre /dev/md1 et /devfs/md/1?
Autre exemple: dans /dev de l'initrd, toujours celui créé pour un kernel sans devfs, il y a bien /dev/console et /dev/hdc et /dev/null, le reste étant lien symbolique (cassé mais c'est logique) vers devfs, dont /dev/md qui pointe sur /devfs/md. Même question que ci dessus, quid de /dev/md1 qui n'existe nulle part?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Luc Coulon (f5ibh) a écrit :
[...]
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*
Hmmh:
Dans script de l'initrd:
ROOT=/dev/md1
[...]
mdadm -A /devfs/md/1 -R -u [...] /dev/hdc6
Le kernel compilé qui est lié à ce initrd est compilé avec devfs, j'ai
créé l'initrd avec -r /dev/md1 Comment au démarrage, la machine doit
trouver ses petits entre /dev/md1 et /devfs/md/1?
Autre exemple: dans /dev de l'initrd, toujours celui créé pour un kernel
sans devfs, il y a bien /dev/console et /dev/hdc et /dev/null, le reste
étant lien symbolique (cassé mais c'est logique) vers devfs, dont
/dev/md qui pointe sur /devfs/md. Même question que ci dessus, quid de
/dev/md1 qui n'existe nulle part?
[...] 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*
Hmmh:
Dans script de l'initrd:
ROOT=/dev/md1 [...] mdadm -A /devfs/md/1 -R -u [...] /dev/hdc6
Le kernel compilé qui est lié à ce initrd est compilé avec devfs, j'ai créé l'initrd avec -r /dev/md1 Comment au démarrage, la machine doit trouver ses petits entre /dev/md1 et /devfs/md/1?
Autre exemple: dans /dev de l'initrd, toujours celui créé pour un kernel sans devfs, il y a bien /dev/console et /dev/hdc et /dev/null, le reste étant lien symbolique (cassé mais c'est logique) vers devfs, dont /dev/md qui pointe sur /devfs/md. Même question que ci dessus, quid de /dev/md1 qui n'existe nulle part?
Le 30.03.2005 18:31:56, daniel huhardeaux a écrit :
Jean-Luc Coulon (f5ibh) a écrit :
[...] 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*
Hmmh:
Dans script de l'initrd:
ROOT=/dev/md1 [...] mdadm -A /devfs/md/1 -R -u [...] /dev/hdc6
Le kernel compilé qui est lié à ce initrd est compilé avec devfs, j'ai créé l'initrd avec -r /dev/md1 Comment au démarrage, la machin e doit trouver ses petits entre /dev/md1 et /devfs/md/1?
Autre exemple: dans /dev de l'initrd, toujours celui créé pour un kernel sans devfs, il y a bien /dev/console et /dev/hdc et /dev/null, le reste étant lien symbolique (cassé mais c'est logique) vers devfs, dont /dev/md qui pointe sur /devfs/md. Même question que ci dessus, quid de /dev/md1 qui n'existe nulle part?
Normalement, c'est à pivot-root de faire le basculement de système de fichier. mais je ne me suis jamais penché en détails sur le mécanisme .
J'ai un lvm sur un raid1. Si je prends l'initrd à la debiand (option --initrd de make-kpkg), je *dois* compiler mon nyau avec le support devfs sinon, ilpanique au démarrage.
Si j'utilise l'initrd avec le script qui vient de la liste lvm (je n'ai plus la référence sous la main), alors, je n'ai pas besoin de devfs. Mais dans ce cas, l'initrd n'est pas modifié si je change les paramètres de mkinitrd lors de la réinstallation d'un nouveau noyau.
Le 30.03.2005 18:31:56, daniel huhardeaux a écrit :
Jean-Luc Coulon (f5ibh) a écrit :
[...]
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*
Hmmh:
Dans script de l'initrd:
ROOT=/dev/md1
[...]
mdadm -A /devfs/md/1 -R -u [...] /dev/hdc6
Le kernel compilé qui est lié à ce initrd est compilé avec devfs,
j'ai créé l'initrd avec -r /dev/md1 Comment au démarrage, la machin e
doit trouver ses petits entre /dev/md1 et /devfs/md/1?
Autre exemple: dans /dev de l'initrd, toujours celui créé pour un
kernel sans devfs, il y a bien /dev/console et /dev/hdc et
/dev/null, le reste étant lien symbolique (cassé mais c'est logique)
vers devfs, dont /dev/md qui pointe sur /devfs/md. Même question que
ci dessus, quid de /dev/md1 qui n'existe nulle part?
Normalement, c'est à pivot-root de faire le basculement de système de
fichier. mais je ne me suis jamais penché en détails sur le mécanisme .
J'ai un lvm sur un raid1. Si je prends l'initrd à la debiand (option
--initrd de make-kpkg), je *dois* compiler mon nyau avec le support
devfs sinon, ilpanique au démarrage.
Si j'utilise l'initrd avec le script qui vient de la liste lvm (je n'ai
plus la référence sous la main), alors, je n'ai pas besoin de devfs.
Mais dans ce cas, l'initrd n'est pas modifié si je change les
paramètres de mkinitrd lors de la réinstallation d'un nouveau noyau.
Le 30.03.2005 18:31:56, daniel huhardeaux a écrit :
Jean-Luc Coulon (f5ibh) a écrit :
[...] 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*
Hmmh:
Dans script de l'initrd:
ROOT=/dev/md1 [...] mdadm -A /devfs/md/1 -R -u [...] /dev/hdc6
Le kernel compilé qui est lié à ce initrd est compilé avec devfs, j'ai créé l'initrd avec -r /dev/md1 Comment au démarrage, la machin e doit trouver ses petits entre /dev/md1 et /devfs/md/1?
Autre exemple: dans /dev de l'initrd, toujours celui créé pour un kernel sans devfs, il y a bien /dev/console et /dev/hdc et /dev/null, le reste étant lien symbolique (cassé mais c'est logique) vers devfs, dont /dev/md qui pointe sur /devfs/md. Même question que ci dessus, quid de /dev/md1 qui n'existe nulle part?
Normalement, c'est à pivot-root de faire le basculement de système de fichier. mais je ne me suis jamais penché en détails sur le mécanisme .
J'ai un lvm sur un raid1. Si je prends l'initrd à la debiand (option --initrd de make-kpkg), je *dois* compiler mon nyau avec le support devfs sinon, ilpanique au démarrage.
Si j'utilise l'initrd avec le script qui vient de la liste lvm (je n'ai plus la référence sous la main), alors, je n'ai pas besoin de devfs. Mais dans ce cas, l'initrd n'est pas modifié si je change les paramètres de mkinitrd lors de la réinstallation d'un nouveau noyau.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
daniel huhardeaux
Jean-Luc Coulon (f5ibh) a écrit :
[...] J'ai un lvm sur un raid1. Si je prends l'initrd à la debiand (option --initrd de make-kpkg), je *dois* compiler mon nyau avec le support devfs sinon, ilpanique au démarrage.
Je compile à l'ancienne:
make dep clean bzImage make modules modules_install mkinitrd -r /dev/md1 /boot/initrd.img-<kernel-version> <kernel-version>
Peut être le problème vient il de là. Et en passant devfs=mount à GRUB, ca ne passe pas non plus?
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Jean-Luc Coulon (f5ibh) a écrit :
[...]
J'ai un lvm sur un raid1. Si je prends l'initrd à la debiand (option
--initrd de make-kpkg), je *dois* compiler mon nyau avec le support
devfs sinon, ilpanique au démarrage.
Je compile à l'ancienne:
make dep clean bzImage
make modules modules_install
mkinitrd -r /dev/md1 /boot/initrd.img-<kernel-version> <kernel-version>
Peut être le problème vient il de là. Et en passant devfs=mount à GRUB,
ca ne passe pas non plus?
[...] J'ai un lvm sur un raid1. Si je prends l'initrd à la debiand (option --initrd de make-kpkg), je *dois* compiler mon nyau avec le support devfs sinon, ilpanique au démarrage.
Je compile à l'ancienne:
make dep clean bzImage make modules modules_install mkinitrd -r /dev/md1 /boot/initrd.img-<kernel-version> <kernel-version>
Peut être le problème vient il de là. Et en passant devfs=mount à GRUB, ca ne passe pas non plus?
