Bonjour,
J’ai rencontré une difficulté étrange qui est réglée, mais que j’aimerais comprendre si l’un de vous a une idée.
J’ai un système multiboot avec deux partitions linux, une ancienne partition debian 10 et une nouvelle debian 11. Les deux OS démarrent à partir de la même partition /dev/sda1. Lors de l’installation de Debian 11, mon menu grub a bien été reconfiguré avec debian11 en tête des entrées. Récemment j’ai voulu mettre à niveau Debian 10 pour un test (apt upgrade). 1er résultat : debian 11 a disparu du menu grub. En modifiant l’ordre de boot dans le BIOS, j’ai retrouvé debian 11, j’ai fait un grub-update dans debian 11 et depuis j’ai bien un menu grub avec debian 11, mais debian 10 continue de s’afficher en tête des entrées.
Après consultation de diverses pages internet sur le changement d’ordre des entrées de grub, j’ai fini par installer grub-customizer. Dans debian 11 ce programme m’affichait une liste grub correcte avec debian 11 en tête et je l’ai réenregistrée. Mais mon grub de démarrage était toujours avec debian 10 en tête. Je suis allé dans debian 10 où, avec grub-customizer, j’ai déplacé les entrées debian 11 en tête et mon problème est enfin réglé.
Mais je reste perplexe. Tout se passe comme si seul le grub.cfg de debian10 était pris en compte au démarrage. Quelqu’un a-t-il une explication ?
Concrètement, qu’est-ce que ça signifie ? Qu’est-ce que /dev/sda1 ? Une partition /boot (j’espère que non) ? Une partition EFI (/boot/efi) ? Dans ces cas les deux Debian installent leur chargeur GRUB au même endroit et c’est le dernier qui écrase l’autre.
Grave erreur. Tu peux dire adieu à une configuration saine de GRUB.
Tu peux corriger ton message initial.
Merci de la réponse.
C’est /boot/efi qui est monté sur /dev/sda1 dans debian 10 et debian 11.
Si le dernier écrase l’autre, pourquoi le update-grub sur debian 11 n’a pas rétabli le grub avec debian 11 en tête ? Est-ce que je peux rétablir une configuration saine de grub ?
update-grub ne fait que générer le menu de GRUB du système sur lequel on l’exécute. Si c’est le GRUB de Debian 10 qui est dans la partition EFI, il va chercher /boot/grub/grub.cfg créé par update-grub sous Debian 10. Pour utiliser le grub.cfg de Debian 11, il faut réinstaller le GRUB de Debian 11 dans la partition EFI, en exécutant grub-install
depuis Debien 11.
J’ai lancé un grub-install depuis debian 11 et j’ai effectivement retrouvé le menu grub d’origine. Le menu que j’avais créé avec grub-customizer depuis debian 10 en modifiant l’ordre des entrées fonctionnait, mais il y avait des bizarreries dans l’intitulé des entrées. La logique me semble aussi plus claire maintenant. Merci
Note que la situation se reproduira après chaque mise à jour des paquets grub-* ou shim-* de Debian 10. Pour l’éviter, il faut désinstaller grub-efi-amd64.
Bonjour,
juste par curiosité (car la réponse m’interpelle),
Pourquoi ?
J’ai cherché cet outil dans synaptic, on le trouve et il a même le logo Debian donc fully tested and validated.
Ou alors Debian n’est plus Debian ? M’aurait-on menti ?
Bon dimanche,
J’ai cherché cet outil dans synaptic, on le trouve et il a même le logo Debian donc fully tested and validated
Ce n’est pas tant le fait qu’il ne soit pas validé mais qu’il manipule comme tu peux le lire les fichiers depuis un des deux OS et du coup écrase dans ce cas particulier l’installation produite par l’autre système.
Ou alors Debian n’est plus Debian ? M’aurait-on menti ?
Humour de mauvaise qualité.
et du coup écrase dans ce cas particulier l’installation produite par l’autre système.
et du coup écrase sans prévenir dans ce cas particulier l’installation produite par l’autre système.
On ne m’a pas menti…
grub-install écrase aussi sans prévenir ce qui était précédemment dans le répertoire /boot/efi. Je comprends ceci : les deux systèmes utilisent le même répertoire /boot/efi et le grub utilisé par les deux systèmes est défini par le dernier système qui a fait un grub-install. Chacun des deux systèmes liste bien tous les OS présents sur la machine, simplement il se met en tête de liste, se définit comme système par défaut et nomme les différents systèmes de son point de vue. Il faut bien de toute façon une zone efi commune à tous les systèmes et ce n’est pas illogique que le dernier installe réorganise tout de son point de vue.
Un truc simple et envisageable, àmha, aurait été qu’en cas de plusieurs OS, il y ait plusieurs dossiers dans le dossier maître des boots.
Non ?
Tout bricoleur qui se respecte ne va pas mélanger les vis et les clous dans le même tiroir, il va utiliser autant de boîtes que de types de choses à ranger.
Quel système gérera le « dossier maître des boots » ? Il y a deux systèmes et la construction de la liste des boots est faite par l’un des deux. Il n’y a pas de 3ème système.
Quel système gérera le « dossier maître des boots » ?
Ben, c’t’est évident, c’est l’utilisateur ! Comme moi qui vais chercher des vis ou des clous selon ce que je veux assembler, l’utilisateur demandera un boot pour telle ou telle install, tout simple en passant par un script.
Il n’y a pas de 3e système.
Ben si : l’utilisateur et son script.
Pour répondre à @jipete concernant mon aversion pour grub-customizer :
J’ai eu deux fois l’occasion d’être confronté aux dégâts causés par grub-customizer, la seconde fois pas plus tard qu’hier et ce n’était pas beau à voir. Scripts générateurs de grub.cfg dans /etc/grub.d/ complètement trafiqués, mélange dans les noms des distributions… Pas trouvé de moyen de revenir à la situation de départ. La suppression du paquet a laissé tout le bazar au lieu de restaurer les scripts d’origine.
il manipule comme tu peux le lire les fichiers depuis un des deux OS et du coup écrase dans ce cas particulier l’installation produite par l’autre système.
Non, je ne pense pas. Il ne fait que trafiquer la configuration du système sur lequel on le lance.
Il faut bien de toute façon une zone efi commune à tous les systèmes
Non, pas forcément. Il peut y avoir plusieurs partitions EFI.
Un truc simple et envisageable, àmha, aurait été qu’en cas de plusieurs OS, il y ait plusieurs dossiers dans le dossier maître des boots.
C’est bien le cas : chaque système est censé installer son chargeur dans un sous-répertoire à son nom de /boot/efi/EFI/. Mais ici il s’agit de deux Debian qui ont donc le même nom « debian », d’où conflit.
GRUB permet d’utiliser un autre nom (option --bootloader-id de grub-install, variable GRUB_DISTRIBUTOR de /etc/default/grub), mais la variante de GRUB signée par Debian pour le secure boot UEFI , qui est installée par défaut, a le chemin EFI/debian codé en dur et ne fonctionne pas si on l’installe ailleurs. Pour utiliser un autre nom il faut installer la variante non signée de GRUB, et donc ne pas activer le secure boot dans les options UEFI.
Merci pour ces précisions bien détaillées.
Et au final, Clochette n’a pas apprécié mon humour et pourtant, à te lire, je n’ai pas complètement tort, il y a des choses inadmissibles :
la variante de GRUB signée par Debian pour le secure boot UEFI , qui est installée par défaut, a le chemin EFI/debian codé en dur et ne fonctionne pas si on l’installe ailleurs.
Non, pas forcément. Il peut y avoir plusieurs partitions EFI.
Dans mon cas il y a une seule partition /dev/sda1 sur laquelle est montée /boot/efi. Dans /boot/efi/EFI je trouve effectivement une série de répertoires nommés ASUS, Boot, debian, ubuntu, Microsoft. Je comprends que chaque OS puisse mettre à jour le répertoire qui le concerne (les boîtes de Jipete bricoleur) et que les deux Debian utilisent la même boîte. Mais je comprends moins bien où est la liste maître affichée par Grub et, s’il y avait effectivement deux partitions efi, /dev/sda1 et /dev/sda2, comment le BIOS choisit-il la partition de démarrage ?
où est la liste maître affichée par Grub
Dans le cas de Debian, le menu de GRUB est défini dans le fichier /boot/grub/grub.cfg du système qui a installé GRUB. Le fichier EFI/debian/grub.cfg éventuellement présent dans la partition EFI ne fait que charger /boot/grub/grub.cfg.
s’il y avait effectivement deux partitions efi, /dev/sda1 et /dev/sda2, comment le BIOS choisit-il la partition de démarrage ?
Le firmware UEFI a une mémoire non volatile (NVRAM) contenant des variables d’amorçage Boot* pointant vers les différents chargeurs installés et l’ordre de priorité. On peut les afficher et les manipuler avec la commande efibootmgr
. En principe, le chargeur installé en dernier se met en premier dans l’ordre (« poussez-vous de là que je m’y mette »).
Du moins en théorie. En pratique, certains firmwares UEFI ne tiennent pas compte de BootOrdrer et appliquent un ordre défini dans les paramètres UEFI, ou utilisent le chargeur présent dans le répertoire EFI/Boot (appelé « chemin de support amovible ») de la première partition EFI trouvée, voire le chemin du chargeur Microsoft codé en dur.
Un grand merci aux intervenants de ce fil de discussion et spécialement à Pascal Hambourg. Grâce à vous, je comprends beaucoup mieux le fonctionnement de grub. C’est un sujet important pour tous les debianistes. Jusqu’ici ce que j’avais trouvé de plus éclairant, c’est ce tuto https://www.malekal.com/grub-la-configuration-grub-cfg-commande-et-dossier-boot/