Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Bon déjà à ce moment là, je croise les doigts mais évidement :
Première fois que je vois ce paquet grub-cloud-amd64 
Je suis paumé 
Sans UFI j'aurai tenté un truc du genre :
Mais j'ai un peu (beaucoup) peur de perdre l'accès à la machine (distante) lors du reboot.
Merci pour toute aide que vous pourriez m'apporter.
Dernière modification par greg40 (07-11-2022 10:13:52)
Hors ligne
Première fois que je vois ce paquet grub-cloud-amd64
Extrait de la description du paquet :
You don't want to use this package outside of cloud images.
C'est une image de cloud ?
Normalement on installe plutôt grub-efi-amd64 ou grub-pc selon le mode d'amorçage.
D'après efibootmgr, le système a été amorcé par le réseau (BootCurrent = Boot0005 = PXE) ?
Il vaut mieux montrer que raconter.
Hors ligne
C'est une image de cloud ?
Oui, C'est une machine OVH, le truc c'est qu'ils modifie leurs images d'installation régulièrement et en fonction de quand tu installes ton serveur tu te retrouve avec de petites variations.
D'après efibootmgr, le système a été amorcé par le réseau (BootCurrent = Boot0005 = PXE) ?
A priori non... Mais effectivement le BootCurrent: 0005 semble l'indiquer...
C'est très étrange cette histoire.
Sur l'interface OVH le boot est bien positionné sur disque dur. En plus ils ont abandonné cette fonctionnalité de boot sur réseaux, et du coup ce genre de problème Grub deviennent très embêtant
Dernière modification par greg40 (04-11-2022 11:09:46)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
J'ai une autre machine UFI chez OVH (debian 11 également) et elle n'a pas grub-cloud-amd64.
Et le efibootmgr -v dit également qu'elle a démarré sur le réseau
Dernière modification par greg40 (04-11-2022 11:16:15)
Hors ligne
L'expression de sed a pour but d'éliminer le numéro de la partition qui contient /boot pour obtenir le nom du disque et y installer GRUB pour l'amorçage BIOS. Exemples :
/dev/sda2 -> /dev/sda
/dev/nvme0n1p2 -> /dev/nvme0n1
mais le résultat est erroné dans le cas d'un ensemble RAID (/dev/md2 ->/dev/md) d'où l'erreur lors de l'exécution de grub-install.
De toute façon, il me semble que l'installation de GRUB dans un ensemble RAID n'est pas possible, ce doit être dans un disque ou une partition de disque. D'après efibootmgr les SSD ont une table de partition au format GPT, donc pour pouvoir installer GRUB BIOS dans leur MBR il faudrait qu'il y ait une partition de type "BIOS boot" sur chacun d'eux. C'est peut-être la partition /dev/nvme0n1p4 sur l'un d'eux, mais il n'y en a pas sur l'autre.
Puisque visiblement l'amorçage est en mode EFI donc l'installation de GRUB pour l'amorçage BIOS ne servirait à rien, je propose de simplement commenter les appels à la fonction install_i386_pc dans /var/lib/dpkg/info/grub-cloud-amd64.postinst.
Accessoirement, j'ai deux autres critiques concernant cette installation :
- Les partitions de swap ne sont pas en RAID, donc risque de plantage en cas de défaillance d'un SSD.
- Il y a bien une partition EFI sur chaque SSD pour la redondance de l'amorçage EFI (en supposant que le chargeur d'amorçage soit installé dans les deux, ce qui est plausible puisque efibootmgr affiche deux variables de boot EFI "debian") mais une seule est montée sur /boot/efi, donc lors d'une mise à jour de grub ou shim le chargeur d'amorçage sera réinstallé seulement sur celle-ci.
Dernière modification par raleur (05-11-2022 09:32:37)
Il vaut mieux montrer que raconter.
Hors ligne
J'ai examiné le contenu du paquet grub-cloud-amd64. Le fichier postinst contient la fonction suivante qui est exécutée à l'installation du paquet et lors de la mise à jour des paquets grub ou shim :
mais le résultat est erroné dans le cas d'un ensemble RAID (/dev/md2 ->/dev/md) d'où l'erreur lors de l'exécution de grub-install.
Ouah... 
Et effectivement :
Puisque visiblement l'amorçage est en mode EFI donc l'installation de GRUB pour l'amorçage BIOS ne servirait à rien, je propose de simplement commenter les appels à la fonction install_i386_pc dans /var/lib/dpkg/info/grub-cloud-amd64.postinst.
C'est fait. Je tente un dpkg-reconfigure grub-cloud-amd64 ?
Je me demandais si je ne pouvais désinstaller ce paquet. Je pense que c'est un des errements des images OVH...
Accessoirement, j'ai deux autres critiques concernant cette installation :
- Les partitions de swap ne sont pas en RAID, donc risque de plantage en cas de défaillance d'un SSD.
Oui c'est clairement moche
Je pourrais swap off, recréer le raid à la main, et swap on. Bon après cette machine à beaucoup de RAM et le swap n'a tout simplement jamais été utilisé depuis l'installation...
Il y a bien une partition EFI sur chaque SSD pour la redondance de l'amorçage EFI (en supposant que le chargeur d'amorçage soit installé dans les deux, ce qui est plausible puisque efibootmgr affiche deux variables de boot EFI "debian") mais une seule est montée sur /boot/efi, donc lors d'une mise à jour de grub ou shim le chargeur d'amorçage sera réinstallé seulement sur celle-ci.
J'ai monté la partition nvme0n1p1 et il y a bien le chargeur d'amorçage.
Il n'y a pas eu de changement lors de cette mise à jour Grub
Mais c'est clairement un point à vérifier à chaque mise à jour de Grub. De toute façon, je ne crois pas qu'on puisse mettre ça en RAID.
Hors ligne
Je tente un dpkg-reconfigure grub-cloud-amd64 ?
A vrai dire l'exécution du script postinst de grub-cloud-amd64 est déclenchée par un trigger après la mises à jour des paquets grub*, donc je ne sais pas vraiment comment on relance ça.
Je me demandais si je ne pouvais désinstaller ce paquet.
Si tu désinstalles ce paquet, le chargeur d'amorçage ne sera plus mis à jour dans la partition EFI après la mise à jour des paquets grub*. Il faudrait le remplacer par grub-efi-amd64.
Mais grub-cloud-amd64 est intéressant car il installe le chargeur GRUB UEFI avec les options --no-nvram et --force-extra-removable qui font ce dernier ne pas dépendre des variables de boot EFI, peu fiables d'après mon expérience. On peut activer ces deux options dans la configuration du paquet grub-efi-amd64, mais ce n'est pas par défaut.
Il n'y a pas eu de changement lors de cette mise à jour Grub
Normal, l'erreur lors de l'installation de GRUB pour BIOS a interrompu le script postinst avant l'installation de GRUB pour EFI.
je ne crois pas qu'on puisse mettre ça en RAID
On peut, mais c'est un hack. Il faut créer un ensemble RAID1 (miroir) avec --metadata=1.0 (superbloc à la fin, très important), le formater en FAT et le monter sur /boot/efi. La création des variables de boot EFI par grub-install ne fonctionne pas dans cette configuration car /boot/efi n'est pas une partition simple donc il faut activer les deux options mentionnées plus haut, ou éventuellement créer les variables de boot EFI à la main avec efibootmgr.
L'alternative consiste à maintenir des partitions EFI indépendantes montées sur des répertoires différents et soit synchroniser leur contenu après chaque mise à jour de grub, soit installer le chargeur dans chaque partition additionnelle.
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne