D’accord ça je comprends bien, mais dans mon esprit chargeur amovible fait référence à un support extérieur comme une clé USB ou autre sur laquelle on installerait GRUB…
Serait-ce le cas également lorsqu’on l’installe sur une partition autre que celle contenant le système de fichiers racine comme ici sur la partition EFI?
Je vais essayer comme tu l’as cité en ligne de commande de réinstaller grub.
Ben ouais, l’appellation n’est pas très explicite et n’est en rien spécifique aux supports amovibles. Moi-même je n’ai pas compris sa signification la première fois que l’installateur m’a posé la question. Je trouverais plus clair que ça s’appelle “l’emplacement du chargeur par défaut”, mais c’est comme ça.
Je ne comprends pas cette question.
Le cas de quoi ? Lorsqu’on installe quoi hors de la racine ?
Tu m’as répondu dans la 1ère réponse en fait, sur la compréhension de l’expression “support amovible”.
Lorsqu’on installe GRUB sur une partition qui n’est pas celle qui contient le système de fichiers racine, en l’occurence ici la partition EFI.
La question n’a pas de sens et je ne comprends pas où tu veux en venir. Le chargeur (core image) de GRUB EFI doit être installé dans une partition système EFI. Cette partition ne peut être la racine et vice versa, donc la core image de GRUB EFI ne peut pas être installée dans la racine. Si tu fais référence à /boot/grub, qui ne contient pas la core image, ça peut être n’importe où.
Oui, et dans ce cas là c’est cette partition qui est désignée comme “support amovible” où bien comme tu l’as judicieusement suggéré, devrait être dénominé “l’emplacement du chargeur par défaut”…
Non. L’emplacement du chargeur par défaut ou chemin de périphérique est, comme son nom l’indique, un chemin : /boot/boot<arch>.efi sur la partition système EFI (où <arch> désigne l’architecture du firmware UEFI, ia32 ou x64 sur x86), pas la partition elle-même.
(edit parce que ce forum masque le texte entre chevrons s’il n’est pas entre quotes)
On est d’accord. 
Bon de toute façon ça ne marche pas non plus, c’est qu’il y a un problème ailleurs…
Si j’enleve l’iso et que je boote la VM, j’ai ce message qui apparait pendant un court instant :
Fsw ERROR: InstallMultipleProtocolInterfaces Returned 2
Puis ça bascule sur le Shell…
Dans le shell UEFI, tu as essayé de lancer GRUB à la main ? Ce shell est un peu comme le command.com de DOS.
PS : juste pour être sûr, tu as bien formaté la partition système EFI en FAT ?
J’ai essayé de lui passer :
\EFI\debian\grubx64.efi
comme j’ai pu retrouver la ligne sur le net mais sans succès, après en démarrage shell à ce niveau je ne connais pas les commandes 
Oui elle est en FAT32.
Les commandes sont cd, dir comme sous DOS/Windows pour se déplacer et afficher le contenu des répertoires. Il y a peut-être aussi un help pour afficher la liste des commandes. Je ne pourrai pas t’aider beaucoup plus car je n’ai pas de shell UEFI sous la main.
C’est pas grave, merci quand même pour toutes ces réponses apportées, je vais essayer de me débrouiller tout seul à glâner des infos sur le net et je reviens dès que j’aurai avancé un peu.
Bon le problème est réglé, j’ai refait une VM toute neuve avec EFI activé dès le départ dans la config, et j’ai à la fin dû quand même installer grub à la mano en chroot, car l’installateur plantait je ne sais pour quelle raison…
En l’occurence il utilise la commande "grub-install dummy. J’ai donc réutilisé cette commande en chroot plutot que de passer les options précédemment citées à grub-install, et ça fonctionne.
Mais… Mais UEFI ne mémorise pas l’entrée Debian dans les options de démarrage, je ne sais pas pour quelle raison mais je penche plus sur un bug de Virtualbox dans ce cas là… Il me faut donc soit à chaque boot entrer les commandes suivantes dans le shell :
FS0: (chemin de la partition EFI)
\EFI\debian\grubx64.efi
Où bien comme je l’ai fait ultérieurement, modifier le fichier startup.nsh et y ajouter ces deux lignes… Je retombe quand même sur le shell, mais ensuite le lancement se fait automatiquement après quelques secondes…
Peux-tu m’éclairer sur ce point. C’est bien une Jessie que j’ai installé en VM avec UEFI, et j’ai fait une simulation d’installation de grub-pc à la suite, mais il semble impossible de faire cohabiter les deux versions puisque apt propose de désinstaller grub-efi…
Y’a t-il une manip particulière à faire?
Ah ouais, j’avais oublié ce détail pénible…
Effectivement les paquets grub-${ARCH} sont incompatibles entre eux. Mais pas les paquets grub-${ARCH}-bin. Ce n’est pas grave si apt-get désinstalle grub-efi et grub-efi-amd64 pour installer grub-pc, du moment qu’il laisse grub-efi-amd64-bin.
Le seul inconvénient, c’est que seul le chargeur correspondant au paquet grub-${ARCH} présent sera réinstallé automatiquement en cas de mise à jour du paquet.
Donc en fait il suffit de conserver le/s binaire/s pour pouvoir démarrer aussi bien en BIOS qu’en UEFI. Le seul incovénient est que seul le paquet grub-$(ARCH) installé sera mis à jour…?
Le système n’a besoin d’aucun paquet grub-* pour démarrer.
Ces paquets servent à installer et configurer le chargeur, ils ne contiennent pas le chargeur. Le chargeur, c’est ce qui est dans /boot/grub, le MBR et la partition système EFI, et ça ne fait pas partie des paquets donc ça restera après leur désinstallation.
Les paquets grub-${ARCH} contiennent essentiellement des scripts qui appellent update-grub pour regénérer la configuration du menu de démarrage dans grub.cfg lors de l’installation, suppression ou mise à jour d’un noyau. En leur absence, il reste possible d’exécuter la commande manuellement.
Les paquets grub-common et grub2-common contiennent notamment les commandes update-grub et grub-install qui ne servent que pour installer et configurer le chargeur, pas pour le faire fonctionner.
Evidemment que seuls les paquets installés sont mis à jour. Mettre à jour un paquet non installé n’a pas de sens. Ce n’est pas ce que je voulais dire.
Lors de l’installation d’un paquet grub-${ARCH}, ses scripts de post-installation installent le chargeur correspondant selon les paramètres spécifiés lors de la configuration du paquet en appelant grub-install et update-grub. Ces scripts sont exécutés à nouveau à chaque mise à jour du paquet comme ce fut le cas lors de la mise à jour pour corriger la faille concernant la saisie des mots de passe. Si un chargeur a été installé par un paquet grub-${ARCH} qui a été ensuite été désinstallé, il ne sera pas mis à jour.
Ok je comprends. En d’autres termes et pour donner un exemple, dans mon cas si j’installe grub-pc il va invoquer la suppression de grub-efi, mais je pourrais toujours faire un update-grub manuellement.
Qu’en est-il des appels à update-grub lors de mises à jour de certains paquets qui ont besoin d’invoquer cette commande? La mise à jour va t’elle quand même se faire automatiquement pour les deux modes de boot où bien uniquement pour l’ARCH dont le paquet est présent, ou bien faudra t’il passer update-grub manuellement, ou bien elle ne se fera exclusivement que pour l’ARCH dont le paquet est présent?
La faille avec la touche “backspace”?
Par défaut il n’y a qu’un seul fichier /boot/grub/grub.cfg, donc commun à toutes les architectures. Il peut y avoir des différences dans le fichier généré, par exemple une option pour entrer dans les paramètres de réglage du firmware UEFI n’est ajoutée que si le système a démarré en mode UEFI, mais c’est marginal.
Oui. La mise à jour des paquets grub-* seule ne suffit pas à corriger la faille puisqu’elle est présente dans le chargeur d’amorçage, qui ne fait pas partie des paquets grub-*. Il fallait donc réinstaller le chargeur après la mise à jour des paquets, ce que fait le script de post-installation si le paquet a été configure correctement.
Oui bien sûr, mais étant donné que les deux paquets grub-$(ARCH) ne peuvent cohabiter, update-grub mettra t-il à jours toutes les lignes, où bien uniquement celles concernant le paquet présent?
Et finalement j’ai une dernière question, qui sort un peu du sujet ici : quelle est la meilleure technique pur faire un backup complet d’une installation?
Je sais qu’on peut également créer son propre ISO d’installation à partir d’un backup système, mais est-il possible de faire des ISO incrémentales?
update-grub regénère tout le fichier grub.cfg en faisant appel aux scripts dans /etc/grub.d/ qui ne dependent pas du paquet grub-${ARCH} installé. Concernant les entrées de menu des noyaux Linux, il n’y a aucune différence.
Il n’y a pas de meilleure solution absolue. Quel est ton critère d’optimisation ? (question purement rhétorique)