Jourbon.
J'utilise Debian Squeeze. Je voudrais créer un multiboot avec Debian testing. Utilisant LVM je souhaite installer testing dans un unique volume logique en utilisant debootstrap, puis démarrer ce système depuis le GRUB actuellement installé. Sur le système actuel /boot est sur une partition primaire et le reste en LVM. Je n'ai qu'un seul VG. Voici comment j'ai procédé, j'espère que quelqu'un pourra me dire pourquoi, vous l'imaginez bien, ça ne fonctionne pas.
- Création du volume logique, formatage en ext4, montage sur /debtest
- debootstrap de testing
- chroot, mise à jour, installation de linux-image, grub2 (à priori inutile pour ce que je veux faire), locales
- update-initramfs
- exit du chroot
Ensuite je me suis dit, il faut créé une entrée dans /etc/grub.d/40_custom, en fait pas la peine grub va faire ça automatiquement. Bon j'ai testé une entrée dans 40_custom écrite par mes soins et l'entrée ajoutée automatiquement c'est le même résultat.
Donc, hors du chroot, lançons update-grub :
root@medusa:~# update-grub
Generating grub.cfg …
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
Found Debian GNU/Linux (wheezy/sid) on /dev/mapper/medusa-debian_testing
done
Chouette me dis-je, voyons voir le grub.cfg généré :
root@medusa:~# grep -Ev "$|#" /boot/grub/grub.cfg
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}
insmod lvm
insmod part_msdos
insmod ext2
set root='(medusa-usr)'
search --no-floppy --fs-uuid --set d3df3766-f68f-4d57-95f1-c3158ec83224
if loadfont /share/grub/unicode.pf2 ; then
set gfxmode=640x480
load_video
insmod gfxterm
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set 98050ee4-d62b-449d-9d44-89c8bae2b903
set locale_dir=($root)/grub/locale
set lang=fr
insmod gettext
set timeout=5
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
menuentry 'Debian GNU/Linux, avec Linux 2.6.32-5-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set 98050ee4-d62b-449d-9d44-89c8bae2b903
echo 'Chargement de Linux 2.6.32-5-amd64 …'
linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/medusa-root ro quiet
echo 'Chargement du disque mémoire initial …'
initrd /initrd.img-2.6.32-5-amd64
}
menuentry 'Debian GNU/Linux, avec Linux 2.6.32-5-amd64 (mode de dépannage)' --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set 98050ee4-d62b-449d-9d44-89c8bae2b903
echo 'Chargement de Linux 2.6.32-5-amd64 …'
linux /vmlinuz-2.6.32-5-amd64 root=/dev/mapper/medusa-root ro single
echo 'Chargement du disque mémoire initial …'
initrd /initrd.img-2.6.32-5-amd64
}
menuentry "Debian GNU/Linux (wheezy/sid) (on /dev/mapper/medusa-debian_testing)" {
insmod lvm
insmod part_msdos
insmod ext2
set root='(medusa-debian_testing)'
search --no-floppy --fs-uuid --set 61ab16ea-3b8e-4188-8382-71ccda04ff3e
linux /boot/vmlinuz-3.2.0-4-rt-amd64 root=/dev/dm-8
initrd /boot/initrd.img-3.2.0-4-rt-amd64
}
if [ -f $prefix/custom.cfg ]; then
source $prefix/custom.cfg;
fi
Et bien ça ne fonctionne pas. GRUB boot (l'initrd je suppose) qui ne trouve pas son rootfs et me rend la main sur un busybox :(
Voilà ce que j'ai tenté :
- Créer un /etc/mtab et /etc/fstab qui vont bien dans le chroot (je n'ai pas relancé le update-initramfs suite à l'ajout du fstab mais je ne pense pas que ça change quelque chose, si ?
- C'est tout en fait. J'attends vos idées lumineuses avec impatience.
# une piste, le nommage des tes roots ?
Posté par NeoX . Évalué à 2.
sur celle qui marche :
sur celle qui ne marche pas
alors que grub le trouve sous
[^] # Re: une piste, le nommage des tes roots ?
Posté par Marotte ⛧ . Évalué à 2.
J'ai essayé en modifiant le grub.cfg en mettant mapper/medusa-debian_testing à la place de dm-8, ça ne marche pas plus.
D'ailleurs quand je fais la commande mount après avoir montée /dev/mapper/medusa-debian_testing sur /debtest ça m'affiche :
/dev/dm-8 on /debtest type ext4 (rw)
Comme pour les autres volumes :
/dev/dm-0 on / type ext3 (rw,errors=remount-ro)
etc…
Je suis donc en ext4 et pas en ext3 mais je suppose que si il y avait un problème j'aurais un message plus parlant non ? Visiblement le module GRUB s'appelle encore ext2 (insmod ext2).
Lors de l'installation de GRUB dans le chroot j'ai essayé de l'installer sur /dev/mapper/medusa-debian_testing qui m'était proposé avec comme autre choix /dev/sda, mais l'installation n'a pas réussie. Je me suis dit que ça pourrait être bien d'avoir GRUB sur mon volume logique si jamais je pouvais pas booter directement depuis le GRUB principal.
Je pense qu'il y a un problème lors de la génération de l'initrd faite depuis le chroot mais je n'arrive vraiment pas à trouver.
[^] # Re: une piste, le nommage des tes roots ?
Posté par NeoX . Évalué à 4.
question comme ca, il me semble que pour avoir un root en LVM il faut que LVM soit present dans le initrd
tu as suivi toute la procedure qui en parle pour generer l'initrd qui va bien à l'interieur de ton chroot ?
[^] # Re: une piste, le nommage des tes roots ?
Posté par Marotte ⛧ . Évalué à 2.
C'est là que ça doit coincer en effet.
Pour le reste, que je mette /dev/mapper/medusa-debian_testing ou /dev/dm-8 ou que j'utilise un UUID j'ai le même message quand je me retrouve sur busybox : ALERT! /dev/mapp…. …. No such file.
Je vais chercher, à nouveau, une doc.
[^] # Re: une piste, le nommage des tes roots ?
Posté par NeoX . Évalué à 2.
c'est donc clairement que tu n'as pas integré le LVM dans la sequence de demarrage par l'ajout des scripts ou des fichiers dans /etc/initramfs de ton chroot
et que tu n'as pas recaculé l'initrd (toujours dans le chroot)
avant d'entrer dans le chroot oublie pas le
mount --bind /boot /path/to/chroot/bootafin que les fichiers generés le soit au bon endroit.
[^] # Re: une piste, le nommage des tes roots ?
Posté par Marotte ⛧ . Évalué à 2.
Tu sous-entends que je dois placer le noyau et l'initrd sur ma partition /boot primaire et que je peux pas les avoir sur le lecteur logique ?
[^] # Re: une piste, le nommage des tes roots ?
Posté par NeoX . Évalué à 2.
je sous entend qu'il n'y a qu'un seul GRUB sur ta machine, donc un seul /boot.
apres si tu veux chainer tes grubs c'est possible,
ca n'empechera pas que tu devras dire à GRUB qu'il y a un LVM sur lequel il faudra aller chercher le noyau…
seulement je ne suis pas sur que GRUB sache aller taper dans un VG pour trouver ses fichiers,
mais je peux me tromper vu que je n'utilises que rarement LVM,
[^] # Re: une piste, le nommage des tes roots ?
Posté par Marotte ⛧ . Évalué à 2.
J'avais pensé au chainage mais installer (le secteur de démarrage) GRUB sur une partition c'est déjà pas recommandé et pour le faire sur un volume logique il y a une astuce que j'ai pas trouvé. Le message d'erreur me dit en substance : « Installer sur une partition c'est pas bien mais c'est parfois nécessaire, par exemple sur un volume logique. » Je n'ai pas trouvé comment forcer.
Et bien j'ai déjà fait des installations tout en LVM (y compris /boot) ça fonctionne, donc ça devrait pouvoir marcher.
Il me semble clair que c'est mon mkinitramfs qui n'inclu pas les outils LVM, dans la log (option -v) je le vois par exemple intégrer des binaires pour udev mais à l'étape du hook lvm2 nada, alors qu'il devrait inclure quelques fichiers.
Il faut que je regarde de ce côté. J'ai vu qu'il existait aussi dracut pour créer l'initrd mais ça n'a pas l'air plus simple à priori.
[^] # Re: une piste, le nommage des tes roots ?
Posté par NeoX . Évalué à 2.
sauf que, comment tu veux dire à GRUB d'aller chercher le noyau, l'initrd, si c'est justement l'initrd qui contient les infos de LVM ?
c'est pour ca que je te proposais plus tot de mettre ton nouveau noyau et ton initrd sur la partition /boot qui n'est pas dans le lvm
ainsi grub accede bien à toutes les infos, et ensuite seulement c'est le noyau et initrd qui peuvent avoir du mal à trouver le LVM pour monter le /
[^] # Re: une piste, le nommage des tes roots ?
Posté par Marotte ⛧ . Évalué à 3.
Si jamais quelqu'un passe sur ce fil de discussion je précise.
En copiant les 4 fichiers (vmlinuz, initrd, system.map et config) sur mon /boot hors LVM ça fonctionne bien.
Par contre suite au grub-update je suis obligé d'éditer manuellement le grub.cfg pour changer le root= pour ce noyau. Je vais pas chercher plus loin. Merci à tous.
[^] # Re: une piste, le nommage des tes roots ?
Posté par Jean-Yves LENHOF (site web personnel) . Évalué à 0.
update-initramfs -k all -u ?
Au besoin tu peux avoir besoin de regarder la variable MODULES dans /etc/initramfs-tools/initramfs.conf
[^] # Re: une piste, le nommage des tes roots ?
Posté par Marotte ⛧ . Évalué à 2.
Oui j'utilise update-initramfs, la variable MODULES est à « most ». Je n'ai pas encore réessayé mais je pense que c'est au niveau de /etc/initramfs-tools/hooks qu'il faut que je fasse quelque chose. Je vais aussi essayer en collant l'initrd et le noyal sur ma partoche /boot qui est hors LVM.
Merci à tous pour vos conseils.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.