Re: Luks/lvm => migration vers un nouveau disque : grub rescue grub error lvmid/48r3xxxx
Le 14 juillet 2024 Greg a écrit : > MAJ de /etc/crypttab pour y ajouter mon luks du sdc2 (nouveau disque) > # blkid | grep 3ca2c544 > /dev/sdc2: UUID="3ca2c544-2104-4e57-9a17-d636921a7b8a" > TYPE="crypto_LUKS" PARTUUID="fae97942-02" > > # grep 3ca2c544 /etc/crypttab > 202407 UUID=3ca2c544-2104-4e57-9a17-d636921a7b8a none luks,discard > > # update-grub ou update-initramfs -c -u => donne le même resultat au > boot ... grub rescue > "grub error lvmid/48r3 ." not found(c'est le VG UUID de mon > nouveau lvm) update-initramfs ne s'occupe que du root actuel, et s'il est dans /etc/crypttab crée une ligne crypttab dans le initramfs. Mais ne prend pas le futur root. Tu peux le vérifier avant reboot avec : mkdir ramfs unmkinitramfs -v /boot/initrd.img- ramfs/ cat ramfs/main/cryptroot/crypttab Perso je passe par un autre truc pour faire les cryptsetup donc je n'ai jamais eu à vérifier, mais ça devrait peut-être se régler en faisant la modif crypttab et update-initramfs en rescue. Ou tout simplement en modifiant le initramfs si tu maîtrise cpio.
Re: Luks/lvm => migration vers un nouveau disque : grub rescue grub error lvmid/48r3xxxx
j'ai potentiellement répondu un peu trop vitre: ma réponse précédente n'est valable que si tu utilises KVM/Qemu. Et si tu utilises bien KVM/Qemu, tu peux aussi ne pas être radin sur la taille des disques virtuels: sauf si tu spécifies explicitement d'allouer entièrement la taille maximale du disque lors de la création de celui-ci, l'allocation est dynamique, donc si tu ne mets que 1 Go sur un disque virtuel de 1 To, l'espace occupé ne représente que 1 Go, si je me souviens bien.
Re: Luks/lvm => migration vers un nouveau disque : grub rescue grub error lvmid/48r3xxxx
Bonjour, j'ai pas lu dans le détail parce que, simplement je me suis posé la question: pourquoi, si c'est possible (et apparemment ça l'est même si je n'ai jamais pratiqué), ne pas agrandir le disque virtuel actuel plutôt qu'en créer un nouveau plus grand? on se retrouve alors ensuite avec une problématique classique d'agrandissement des partitions du disque: https://computingforgeeks.com/how-to-extend-increase-kvm-virtual-machine-disk-size/
Luks/lvm => migration vers un nouveau disque : grub rescue grub error lvmid/48r3xxxx
Bonjour, J'ai ma VM debian qui est un peu à l'étroit côté disque * nouveau disque de 50Go * /bootsur sdc1 (UUID="4a43caa0-2f0a-414a-8ba5-455aa45d8bc0") * luks+lvm sur sdc2 (un lukOpen à la main fonctionne) Je copie ce qui est sur l'ancien disque sur le nouveau (avec les rsync pour /boot / /var, exclusion des /run et consorts) je mount tout ça + du bind pour préparer un chroot : for i in /sys /proc /dev; do mount --bind "$i" /media/202407/slash"$i"; done ; for p in var boot ; do mount --bind /media/202407/$p /media/202407/slash/$p ; done && /sbin/chroot /media/202407/slash MAJ de /etc/crypttab pour y ajouter mon luks du sdc2 (nouveau disque) # blkid | grep 3ca2c544 /dev/sdc2: UUID="3ca2c544-2104-4e57-9a17-d636921a7b8a" TYPE="crypto_LUKS" PARTUUID="fae97942-02" # grep 3ca2c544 /etc/crypttab 202407 UUID=3ca2c544-2104-4e57-9a17-d636921a7b8a none luks,discard # update-grub ou update-initramfs -c -u => donne le même resultat au boot ... grub rescue "grub error lvmid/48r3 ." not found(c'est le VG UUID de mon nouveau lvm) J'ai tenté un sed dans /boot/grub/grub.cfg /boot/grub/i386-pc/load.cfg s/3491398d-b897-4ac2-9697-e9793d606c0d/4a43caa0-2f0a-414a-8ba5-455aa45d8bc0/g * 349xx => partition boot "actuelle" (sda1) * 4a4xx => futur boot (sdc1) J'ai raté quoi d'évident ? (c'est forcément un pb interface chaise-clavier) Je pense que grub ne détecte pas mon sdc2 en tant que luks C'est sûrement brouillon, si cela ne l'était pas ... j'aurais ptet trouvé la solution tout seul ... Note : si je boot en sda1 => je suis quand même obligé de faire un luksOpen de mon nouveau disque (sdc2) pour pouvoir monter les "nouvelles" partition (malgrés le crypttab à jour)
