Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
hello,
On 6/4/21 11:59 AM, Renaud Galante wrote:
Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
donc l'id LVM est bien référencé dans ton env mais pas trouvé. Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
Pour t'y retrouver, essaye les commandes pour déterminer si ca vient d'un disque non vu, puis du LVM physical volume qui est censé être dessus, puis des LVM vg et enfin du LVM lv.
- lsblk : liste les "block devices" qui sont visibles (disques, partitions, LVM LV) - blkid : liste les uuid - pvdisplay : qu'en pense-t-il ? - vgdisplay : qu'en pense-t-il ? - pvscan : pleins d'options, notamment "mettre à jour le cache" - vgscan: (idem pvscan)
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg et enfin LVM lv.
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
si il y a une différence, c'est la "présentation" des disques de l'enveloppe de virtu à l'OS qu'elle contient.
si les 2 disques sont sur 2 type de controlleurs differents sous promox, peut-etre que tu n'a pas le driver du 2e controlleur dans l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des échanges de nom de disque apres reboot vu depuis l'OS, genre sdb devient sdc, et sdc devient sdb. Heureusement avec LVM et les uuid, on survit (le nom de disque n'a presque plus d'importance)
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
Liste de diffusion du FRsAG http://www.frsag.org/
oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
c'est quelle version de grub ?
faut peut-etre generer grub après avoir rajouté ton 2e disque dans ta conf LVM ?
On 6/4/21 12:47 PM, Pierre Bourgin wrote:
hello,
On 6/4/21 11:59 AM, Renaud Galante wrote:
Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
donc l'id LVM est bien référencé dans ton env mais pas trouvé. Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
Pour t'y retrouver, essaye les commandes pour déterminer si ca vient d'un disque non vu, puis du LVM physical volume qui est censé être dessus, puis des LVM vg et enfin du LVM lv.
- lsblk : liste les "block devices" qui sont visibles (disques,
partitions, LVM LV)
- blkid : liste les uuid
- pvdisplay : qu'en pense-t-il ?
- vgdisplay : qu'en pense-t-il ?
- pvscan : pleins d'options, notamment "mettre à jour le cache"
- vgscan: (idem pvscan)
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg et enfin LVM lv.
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
si il y a une différence, c'est la "présentation" des disques de l'enveloppe de virtu à l'OS qu'elle contient.
si les 2 disques sont sur 2 type de controlleurs differents sous promox, peut-etre que tu n'a pas le driver du 2e controlleur dans l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des échanges de nom de disque apres reboot vu depuis l'OS, genre sdb devient sdc, et sdc devient sdb. Heureusement avec LVM et les uuid, on survit (le nom de disque n'a presque plus d'importance)
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
autre piste: Côté hyperviseur, peut-etre une sensibilité au "BIOS" émulé par proxmox ou VMware ?
booter ta VM avec un ISO live les commandes lsblk, blkid & co permettrait peut-etre aussi de se faire une idée ?
On 6/4/21 12:55 PM, Pierre Bourgin wrote:
oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
c'est quelle version de grub ?
faut peut-etre generer grub après avoir rajouté ton 2e disque dans ta conf LVM ?
On 6/4/21 12:47 PM, Pierre Bourgin wrote:
hello,
On 6/4/21 11:59 AM, Renaud Galante wrote:
Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
donc l'id LVM est bien référencé dans ton env mais pas trouvé. Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
Pour t'y retrouver, essaye les commandes pour déterminer si ca vient d'un disque non vu, puis du LVM physical volume qui est censé être dessus, puis des LVM vg et enfin du LVM lv.
- lsblk : liste les "block devices" qui sont visibles (disques,
partitions, LVM LV)
- blkid : liste les uuid
- pvdisplay : qu'en pense-t-il ?
- vgdisplay : qu'en pense-t-il ?
- pvscan : pleins d'options, notamment "mettre à jour le cache"
- vgscan: (idem pvscan)
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg et enfin LVM lv.
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
si il y a une différence, c'est la "présentation" des disques de l'enveloppe de virtu à l'OS qu'elle contient.
si les 2 disques sont sur 2 type de controlleurs differents sous promox, peut-etre que tu n'a pas le driver du 2e controlleur dans l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des échanges de nom de disque apres reboot vu depuis l'OS, genre sdb devient sdc, et sdc devient sdb. Heureusement avec LVM et les uuid, on survit (le nom de disque n'a presque plus d'importance)
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Merci pour les réponses.
Je n'avais pas testé le changement de controlleur disque sur la vm. Je suis passé de virtio-scsi-pci (proposé par défault dans proxmox) à lsi et cela fonctionne, ma vm démarre bien.
Je vais voir si j'arrive à trouver une explication plus précise.
Reno.
Le 04/06/2021 à 12:59, Pierre Bourgin a écrit :
autre piste: Côté hyperviseur, peut-etre une sensibilité au "BIOS" émulé par proxmox ou VMware ?
booter ta VM avec un ISO live les commandes lsblk, blkid & co permettrait peut-etre aussi de se faire une idée ?
On 6/4/21 12:55 PM, Pierre Bourgin wrote:
oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
c'est quelle version de grub ?
faut peut-etre generer grub après avoir rajouté ton 2e disque dans ta conf LVM ?
On 6/4/21 12:47 PM, Pierre Bourgin wrote:
hello,
On 6/4/21 11:59 AM, Renaud Galante wrote:
Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
donc l'id LVM est bien référencé dans ton env mais pas trouvé. Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
Pour t'y retrouver, essaye les commandes pour déterminer si ca vient d'un disque non vu, puis du LVM physical volume qui est censé être dessus, puis des LVM vg et enfin du LVM lv.
- lsblk : liste les "block devices" qui sont visibles (disques,
partitions, LVM LV)
- blkid : liste les uuid
- pvdisplay : qu'en pense-t-il ?
- vgdisplay : qu'en pense-t-il ?
- pvscan : pleins d'options, notamment "mettre à jour le cache"
- vgscan: (idem pvscan)
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg et enfin LVM lv.
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
si il y a une différence, c'est la "présentation" des disques de l'enveloppe de virtu à l'OS qu'elle contient.
si les 2 disques sont sur 2 type de controlleurs differents sous promox, peut-etre que tu n'a pas le driver du 2e controlleur dans l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des échanges de nom de disque apres reboot vu depuis l'OS, genre sdb devient sdc, et sdc devient sdb. Heureusement avec LVM et les uuid, on survit (le nom de disque n'a presque plus d'importance)
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
J'ai finalement trouvé la réponse pour faire fonctionner cela avec virtio-scsi-pci:
https://forum.proxmox.com/threads/regression-pve-qemu-kvm-5-1-fail-to-boot-v...
Il fallait que je rajoute le disque dans la liste des disques bootable, sinon seabios ne les charge pas
Merci en tout cas !
Reno.
Le 04/06/2021 à 13:22, Renaud Galante a écrit :
Merci pour les réponses.
Je n'avais pas testé le changement de controlleur disque sur la vm. Je suis passé de virtio-scsi-pci (proposé par défault dans proxmox) à lsi et cela fonctionne, ma vm démarre bien.
Je vais voir si j'arrive à trouver une explication plus précise.
Reno. Le 04/06/2021 à 12:59, Pierre Bourgin a écrit :
autre piste: Côté hyperviseur, peut-etre une sensibilité au "BIOS" émulé par proxmox ou VMware ?
booter ta VM avec un ISO live les commandes lsblk, blkid & co permettrait peut-etre aussi de se faire une idée ?
On 6/4/21 12:55 PM, Pierre Bourgin wrote:
oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
c'est quelle version de grub ?
faut peut-etre generer grub après avoir rajouté ton 2e disque dans ta conf LVM ?
On 6/4/21 12:47 PM, Pierre Bourgin wrote:
hello,
On 6/4/21 11:59 AM, Renaud Galante wrote:
Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
donc l'id LVM est bien référencé dans ton env mais pas trouvé. Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
Pour t'y retrouver, essaye les commandes pour déterminer si ca vient d'un disque non vu, puis du LVM physical volume qui est censé être dessus, puis des LVM vg et enfin du LVM lv.
- lsblk : liste les "block devices" qui sont visibles (disques,
partitions, LVM LV)
- blkid : liste les uuid
- pvdisplay : qu'en pense-t-il ?
- vgdisplay : qu'en pense-t-il ?
- pvscan : pleins d'options, notamment "mettre à jour le cache"
- vgscan: (idem pvscan)
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg et enfin LVM lv.
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
si il y a une différence, c'est la "présentation" des disques de l'enveloppe de virtu à l'OS qu'elle contient.
si les 2 disques sont sur 2 type de controlleurs differents sous promox, peut-etre que tu n'a pas le driver du 2e controlleur dans l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des échanges de nom de disque apres reboot vu depuis l'OS, genre sdb devient sdc, et sdc devient sdb. Heureusement avec LVM et les uuid, on survit (le nom de disque n'a presque plus d'importance)
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
à noter que grub shell propose la commande 'ls' pour lister ce qu'il voit comme périphériques.
cf https://www.gnu.org/software/grub/manual/grub/grub.html#GRUB-only-offers-a-r...
(désolé, j'arrête de balancer 1 mail à chaque idée).
On 6/4/21 12:55 PM, Pierre Bourgin wrote:
oula, j'ai pas vu que tu atterissais dans *grub*, pardon.
c'est quelle version de grub ?
faut peut-etre generer grub après avoir rajouté ton 2e disque dans ta conf LVM ?
On 6/4/21 12:47 PM, Pierre Bourgin wrote:
hello,
On 6/4/21 11:59 AM, Renaud Galante wrote:
Bonjour à tous
J'ai un petit problème à vous soumettre.
Au redémarrage d'une vm sous debian, j'ai le message d'erreur suivant dès le chargement de grub (le menu n’apparaît pas)
error: disk 'lvmid/xxxxxxxxxxxxxxxxxxxxxxxx/YYYYYYYYY' not found
et j’atterris dans le grub rescue.
donc l'id LVM est bien référencé dans ton env mais pas trouvé. Peut-etre que le disque qui contient ce qui manque n'est pas détecté ?
Pour t'y retrouver, essaye les commandes pour déterminer si ca vient d'un disque non vu, puis du LVM physical volume qui est censé être dessus, puis des LVM vg et enfin du LVM lv.
- lsblk : liste les "block devices" qui sont visibles (disques,
partitions, LVM LV)
- blkid : liste les uuid
- pvdisplay : qu'en pense-t-il ?
- vgdisplay : qu'en pense-t-il ?
- pvscan : pleins d'options, notamment "mettre à jour le cache"
- vgscan: (idem pvscan)
Pour reproduire le problème, je suis dans les conditions suivantes: - Ma partition / est un LV situé sur 2 disques (il y avait un seul disque à l'origine, mais un deuxième a été rajouté par la suite suite à un soucis d'espace) - Je n'ai pas de /boot dédié - La VM tourne sous proxmox
Le message est certainement dû au fait que le deuxième disque ne soit pas "lu" au démarrage. J'ai testé différentes configs pour le deuxième disque, à savoir coté LVM ce disque est intégré entièrement (donc pas de partition) ou alors un partitionnement de type dos et gpt,suivi d'un grub-install sur le nouveau disque
il faut vérifier dans l'ordre: les LVM Physical Volume, puis LVM vg et enfin LVM lv.
Je reproduis ce cas sur des vms vierges avec une install debian (buster et bullseye) toute fresh. Dès que je rajoute un disque supplémentaire et que je le rajoute à ma partition / avec toutes les opérations lvm qui vont bien, au reboot, j'atteris sur le grub rescue.
Cependant, si je réalise cette même opération sous vmware, la vm redémarre bien.
Mon problème est vite résolu en agrandissant directement le disque principal, en créant une nouvelle partition, ou en agrandissant la partition si cela est possible, mais je trouve cela tellement plus simple et sécurisant de le faire par lvm. Et cela rend la réduction d'espace plus simple aussi dans le cas de besoin d'espace temporaire et que le client est incapable de mettre toutes ces données à un endroit particulier.
Je me demande donc ce qui pourrait expliquer cette différence de comportement entre 2 techno différentes (KVM et vmware) et s'il y a un moyen de faire fonctionner ce principe avec proxmox / kvm
si il y a une différence, c'est la "présentation" des disques de l'enveloppe de virtu à l'OS qu'elle contient.
si les 2 disques sont sur 2 type de controlleurs differents sous promox, peut-etre que tu n'a pas le driver du 2e controlleur dans l'initramfs de ton OS ? ce serait vraiment tordu mais bon ...
Anecdote: avec RHV (kvm/qemu sauce Red Hat), il arrive que y'ai des échanges de nom de disque apres reboot vu depuis l'OS, genre sdb devient sdc, et sdc devient sdb. Heureusement avec LVM et les uuid, on survit (le nom de disque n'a presque plus d'importance)
SI quelqu'un a une idée,
Merci et bon vendredi à tous !
Reno.
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
-
Pierre Bourgin -
Renaud Galante