J'utilise lvm et mon syst=E8me de ficheirs racine est sous lvm (de m=EAme =20
que le reste, sanuf /boot).
Pour cr=E9er l'initrd, j'utilise un script que j'ai obtenu sur la liste =20
de diffusion de lvm : lvm2create_initrd de Jeff Layton =20
<jtlayton@poochiereds.net>
http://poochiereds.net/svn/lvm2
Ca fonctione parfaitement mais c'est dommade d'utiliser les outils =20
Debian et de faire tourner ce script =E0 la main en fin d'installation du =20
noyau.
Est-ce quelqu'un a l'exp=E9rience de la cr=E9ation de l'initrd pour un =20
fichier racice sous lvm avec les outils Debian ?
Oui, xfs est en module, en fait, je n'ai rien changé à ma config
noyau
qui fonctionne avec le script lvm2create_initrd.
Quelles sont les différences entre l'initrd qui fonctionne (celui cré é par lvm2create_initrd) et celui qui ne fonctionne pas (celui créé par dpkg -i) ?
Une différence essentielle que je n'avais pas remarquée : lvm2create-initrd créé un initrd de type ext2 mkinitrd créé un initrd de type cramfs
J'avais bien cramfs dans monn noyau mais en module. Je refais une compilation (long....) pour l'insérer en dur.
J'ai tenté de créé un initrd ext2 avec mkinitrd (parce qu'il est plus rapide de faire un initrd que de refaire un noyau complet...) mais il échoue avec le message suivant : [] # mkinitrd -o initrd.img-2.6.9-k6-6 2.6.9-k6-6 mkfs.ext2: décompte de blocs corrompus - /dev/fd/3
Autre possibilité : mettre DELAY (par exemple) dans /etc/mkinitrd/mkinitrd.conf
Ca n'a servi à rien : je n'arrive pas jusque là (apparament) dans ma procédure de boot.
Oui, xfs est en module, en fait, je n'ai rien changé à ma config
noyau
qui fonctionne avec le script lvm2create_initrd.
Quelles sont les différences entre l'initrd qui fonctionne (celui cré é
par lvm2create_initrd) et celui qui ne fonctionne pas (celui créé par
dpkg -i) ?
Une différence essentielle que je n'avais pas remarquée :
lvm2create-initrd créé un initrd de type ext2
mkinitrd créé un initrd de type cramfs
J'avais bien cramfs dans monn noyau mais en module. Je refais une
compilation (long....) pour l'insérer en dur.
J'ai tenté de créé un initrd ext2 avec mkinitrd (parce qu'il est plus
rapide de faire un initrd que de refaire un noyau complet...) mais il
échoue avec le message suivant :
[root@tangerine] # mkinitrd -o initrd.img-2.6.9-k6-6 2.6.9-k6-6
mkfs.ext2: décompte de blocs corrompus - /dev/fd/3
Autre possibilité : mettre DELAY=10 (par exemple) dans
/etc/mkinitrd/mkinitrd.conf
Ca n'a servi à rien : je n'arrive pas jusque là (apparament) dans ma
procédure de boot.
Oui, xfs est en module, en fait, je n'ai rien changé à ma config
noyau
qui fonctionne avec le script lvm2create_initrd.
Quelles sont les différences entre l'initrd qui fonctionne (celui cré é par lvm2create_initrd) et celui qui ne fonctionne pas (celui créé par dpkg -i) ?
Une différence essentielle que je n'avais pas remarquée : lvm2create-initrd créé un initrd de type ext2 mkinitrd créé un initrd de type cramfs
J'avais bien cramfs dans monn noyau mais en module. Je refais une compilation (long....) pour l'insérer en dur.
J'ai tenté de créé un initrd ext2 avec mkinitrd (parce qu'il est plus rapide de faire un initrd que de refaire un noyau complet...) mais il échoue avec le message suivant : [] # mkinitrd -o initrd.img-2.6.9-k6-6 2.6.9-k6-6 mkfs.ext2: décompte de blocs corrompus - /dev/fd/3
Autre possibilité : mettre DELAY (par exemple) dans /etc/mkinitrd/mkinitrd.conf
Ca n'a servi à rien : je n'arrive pas jusque là (apparament) dans ma procédure de boot.
Une différence essentielle que je n'avais pas remarquée : lvm2create-initrd créé un initrd de type ext2 mkinitrd créé un initrd de type cramfs
J'avais bien cramfs dans monn noyau mais en module. Je refais une compilation (long....) pour l'insérer en dur.
Bon, ça ne marche pas mieux. J'ai les mêmes messages d'erreur sauf si je mets root=/dev/ram0. Là le cramfs se charge et le /sbin/init commence à s'exécuter mais il plante rapidement avec des messages comme :
initrd-tools: 0.1.74 /sbin/init: 358: cannot open bin/root: No such file umount: Cannot open /proc/mount umount: bin: Invalid argument /sbin§init: 350 cannot create proc/sys/kernel/real-root-dev: Directory nonexistant cat: proc/cmdline: No such file or directory mount: Mounting /devfs on /devfs failed: no such device ... etc ..
Et là, je suis pris d'un doute : le support pour devfs est-il nécessaire pour la création d'un initrd à la debian ?
J'ai tenté de créé un initrd ext2 avec mkinitrd (parce qu'il est pl us rapide de faire un initrd que de refaire un noyau complet...) mais il échoue avec le message suivant : [] # mkinitrd -o initrd.img-2.6.9-k6-6 2.6.9-k6-6 mkfs.ext2: décompte de blocs corrompus - /dev/fd/3
Autre possibilité : mettre DELAY (par exemple) dans /etc/mkinitrd/mkinitrd.conf
Ca n'a servi à rien : je n'arrive pas jusque là (apparament) dans ma procédure de boot.
Une différence essentielle que je n'avais pas remarquée :
lvm2create-initrd créé un initrd de type ext2
mkinitrd créé un initrd de type cramfs
J'avais bien cramfs dans monn noyau mais en module. Je refais une
compilation (long....) pour l'insérer en dur.
Bon, ça ne marche pas mieux. J'ai les mêmes messages d'erreur sauf si
je mets root=/dev/ram0. Là le cramfs se charge et le /sbin/init
commence à s'exécuter mais il plante rapidement avec des messages comme :
initrd-tools: 0.1.74
/sbin/init: 358: cannot open bin/root: No such file
umount: Cannot open /proc/mount
umount: bin: Invalid argument
/sbin§init: 350 cannot create proc/sys/kernel/real-root-dev: Directory
nonexistant
cat: proc/cmdline: No such file or directory
mount: Mounting /devfs on /devfs failed: no such device
... etc ..
Et là, je suis pris d'un doute : le support pour devfs est-il
nécessaire pour la création d'un initrd à la debian ?
J'ai tenté de créé un initrd ext2 avec mkinitrd (parce qu'il est pl us
rapide de faire un initrd que de refaire un noyau complet...) mais il
échoue avec le message suivant :
[root@tangerine] # mkinitrd -o initrd.img-2.6.9-k6-6 2.6.9-k6-6
mkfs.ext2: décompte de blocs corrompus - /dev/fd/3
Autre possibilité : mettre DELAY=10 (par exemple) dans
/etc/mkinitrd/mkinitrd.conf
Ca n'a servi à rien : je n'arrive pas jusque là (apparament) dans ma
procédure de boot.
Une différence essentielle que je n'avais pas remarquée : lvm2create-initrd créé un initrd de type ext2 mkinitrd créé un initrd de type cramfs
J'avais bien cramfs dans monn noyau mais en module. Je refais une compilation (long....) pour l'insérer en dur.
Bon, ça ne marche pas mieux. J'ai les mêmes messages d'erreur sauf si je mets root=/dev/ram0. Là le cramfs se charge et le /sbin/init commence à s'exécuter mais il plante rapidement avec des messages comme :
initrd-tools: 0.1.74 /sbin/init: 358: cannot open bin/root: No such file umount: Cannot open /proc/mount umount: bin: Invalid argument /sbin§init: 350 cannot create proc/sys/kernel/real-root-dev: Directory nonexistant cat: proc/cmdline: No such file or directory mount: Mounting /devfs on /devfs failed: no such device ... etc ..
Et là, je suis pris d'un doute : le support pour devfs est-il nécessaire pour la création d'un initrd à la debian ?
J'ai tenté de créé un initrd ext2 avec mkinitrd (parce qu'il est pl us rapide de faire un initrd que de refaire un noyau complet...) mais il échoue avec le message suivant : [] # mkinitrd -o initrd.img-2.6.9-k6-6 2.6.9-k6-6 mkfs.ext2: décompte de blocs corrompus - /dev/fd/3
Autre possibilité : mettre DELAY (par exemple) dans /etc/mkinitrd/mkinitrd.conf
Ca n'a servi à rien : je n'arrive pas jusque là (apparament) dans ma procédure de boot.
Oui, xfs est en module, en fait, je n'ai rien changé à ma config
noyau
qui fonctionne avec le script lvm2create_initrd.
Quelles sont les différences entre l'initrd qui fonctionne (celui cré é par lvm2create_initrd) et celui qui ne fonctionne pas (celui créé par dpkg -i) ?
Autre possibilité : mettre DELAY (par exemple) dans /etc/mkinitrd/mkinitrd.conf
J'ai finalement résolu ce problème. Il m'étati dfifficile de comparer l'initrd qui fonctionne et celui proposé par une solution Debian car les structures sont complètement différentes.
Après mes essais de l'installeur de cet après-midi, j'ai réussi sans problème à avoir une Sarge qui boote avec l'initrd fourni par la distribution.
J'ai donc monté les deux initrd dans le loopback et, avec un peu d'esprit critique, j'ai fait un diff des deux.
Je me suis aperçu que dans l'initrd qui ne marchait pas il y avait une ligne comme suit dans /etc/lvm/lvm.conf :
library_dir = "/lib/lvm2"
Ce chemin n'existe ni sur mon système si sur le lvm. En revanche, cette ligne est bien présente dans le :etc/lvm/lvm.conf de mon système.
Après l'avoir commentée, le nouvel initrd construit fonctionne parfaitement.
Cette valeur fait partie du lvm.conf livré avec le paquet lvm2. Je vais signaler un bogue sur ce problème.
Oui, xfs est en module, en fait, je n'ai rien changé à ma config
noyau
qui fonctionne avec le script lvm2create_initrd.
Quelles sont les différences entre l'initrd qui fonctionne (celui cré é
par lvm2create_initrd) et celui qui ne fonctionne pas (celui créé par
dpkg -i) ?
Autre possibilité : mettre DELAY=10 (par exemple) dans
/etc/mkinitrd/mkinitrd.conf
J'ai finalement résolu ce problème. Il m'étati dfifficile de comparer
l'initrd qui fonctionne et celui proposé par une solution Debian car
les structures sont complètement différentes.
Après mes essais de l'installeur de cet après-midi, j'ai réussi sans
problème à avoir une Sarge qui boote avec l'initrd fourni par la
distribution.
J'ai donc monté les deux initrd dans le loopback et, avec un peu
d'esprit critique, j'ai fait un diff des deux.
Je me suis aperçu que dans l'initrd qui ne marchait pas il y avait une
ligne comme suit dans /etc/lvm/lvm.conf :
library_dir = "/lib/lvm2"
Ce chemin n'existe ni sur mon système si sur le lvm. En revanche, cette
ligne est bien présente dans le :etc/lvm/lvm.conf de mon système.
Après l'avoir commentée, le nouvel initrd construit fonctionne
parfaitement.
Cette valeur fait partie du lvm.conf livré avec le paquet lvm2. Je vais
signaler un bogue sur ce problème.
Oui, xfs est en module, en fait, je n'ai rien changé à ma config
noyau
qui fonctionne avec le script lvm2create_initrd.
Quelles sont les différences entre l'initrd qui fonctionne (celui cré é par lvm2create_initrd) et celui qui ne fonctionne pas (celui créé par dpkg -i) ?
Autre possibilité : mettre DELAY (par exemple) dans /etc/mkinitrd/mkinitrd.conf
J'ai finalement résolu ce problème. Il m'étati dfifficile de comparer l'initrd qui fonctionne et celui proposé par une solution Debian car les structures sont complètement différentes.
Après mes essais de l'installeur de cet après-midi, j'ai réussi sans problème à avoir une Sarge qui boote avec l'initrd fourni par la distribution.
J'ai donc monté les deux initrd dans le loopback et, avec un peu d'esprit critique, j'ai fait un diff des deux.
Je me suis aperçu que dans l'initrd qui ne marchait pas il y avait une ligne comme suit dans /etc/lvm/lvm.conf :
library_dir = "/lib/lvm2"
Ce chemin n'existe ni sur mon système si sur le lvm. En revanche, cette ligne est bien présente dans le :etc/lvm/lvm.conf de mon système.
Après l'avoir commentée, le nouvel initrd construit fonctionne parfaitement.
Cette valeur fait partie du lvm.conf livré avec le paquet lvm2. Je vais signaler un bogue sur ce problème.
