Grub désactivé après chaque démarrage Windows Le sujet est résolu

Demande d'aide : c'est ici.
Répondre
Avatar de l’utilisateur
piratebab
Site Admin
Site Admin
Messages : 4906
Inscription : 24 avr. 2016, 18:41
Localisation : sud ouest
Status : Hors-ligne

Merci pour ce retour.
Les priorités de boot ne changent pas.
L'option --force-extra-removable à fait le job!
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

[Hors-Sujet - Complément]

Découvrant la commande efibootmgr
que je n'ai jamais due utiliser jusqu'à présent,
je l'ai testée sur mon pc :

Code : Tout sélectionner

$ efibootmgr                                                  
BootCurrent: 0003
Timeout: 1 seconds
BootOrder: 0003,0008,0000,0005
Boot0000* Windows Boot Manager
Boot0003* debian
Boot0005* Manjaro
Boot0008* UEFI : Built-in EFI Shell
Je n'ai aucun problème de démarrage ( GRUB 2 installations Debian)
le choix par défaut étant : Boot0003* debian

Mais je me pose des questions quant aux autres entrées:

Boot0005* Manjaro
j'avais d'abord installé Manjaro avant Debian (histoire de tester) que j'ai écrasé pour Debian ;
je comprends (pas bien) donc qu'il en reste une trace... à la rigueur.

Boot0000* Windows Boot Manager
là je ne comprends vraiment pas d'où sort cette entrée,
la machine étant un barebone (NUC Intel) que j'ai installé moi-même et uniquement en Linux comme décrit plus avant.

La seule explication > cette entrée était présente à la livraison du matériel ???

Question :

puis-je sans risque supprimer :
  • Boot0000* Windows Boot Manager
  • Boot0005* Manjaro
avec respectivement :

Code : Tout sélectionner

efibootmgr -b 0 -B
efibootmgr -b 5 -B
J'attends vos avis avant toute initiative (malheureuse)

Merci.
**Simple Utilisateur** -- Debian stable - XFCE
PascalHambourg
Contributeur
Contributeur
Messages : 876
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

DrPepere a écrit : 13 oct. 2022, 13:53 C'est quoi en fait, ce --force-extra-removable?
Pour répondre, je vais expliquer comment fonctionne l'amorçage UEFI.

En temps normal c'est censé se passer de la façon suivante :
1) Le système d'exploitation installe son chargeur d'amorçage dans un sous-répertoire à son nom dans le répertoire EFI de la partition système EFI. Dans le cas de Debian, c'est donc GRUB (+ shim pour le secure boot) dans EFI/debian.
2) Le système d'exploitation demande au firmware UEFI d'enregistrer ce chargeur d'amorçage avec son chemin dans une variable de boot EFI BootNNNN (où NNNN est un nombre hexadécimal entre 0000 et FFFF) stockée dans la mémoire non volatile de la carte mère, et généralement de la mettre en premier dans l'ordre d'amorçage spécifié par la variable BootOrder.
Ces deux opérations sont réalisées par grub-install. On peut aussi afficher et modifier les variables de boot EFI avec efibootmgr.
3) Au démarrage, le firmware UEFI prend le premier numéro NNNN dans BootOrder et lance le chargeur à l'emplacement spécifié par la variable BootNNNN correspondante. En cas d'échec, le firmware UEFI prend le numéro suivant et ainsi de suite.

Si c'était le seul mécanisme d'amorçage possible, il y aurait un problème : impossible de démarrer avec un chargeur non déclaré dans les variables de boot EFI, notamment dans le cas d'un support amovible d'installation. Pour cela, la spécification UEFI a défini un emplacement spécifique EFI/Boot dans la partition EFI, que le firmware UEFI peut utiliser pour démarrer si aucune variable de boot ne fonctionne. Cet emplacement est appelé "chemin de support amovible" bien qu'il s'applique aussi aux supports non amovibles. Pour simplifier, on peut dire que le chemin de support amovible est le MBR de l'amorçage UEFI.

Certains firmwares UEFI connaissent aussi l'emplacement du chargeur de Windows et peuvent le lancer sans variable de boot EFI.

Par défaut, grub-install n'installe pas GRUB dans le chemin de support amovible, ce qui constitue un handicap puisque le firmware UEFI ne peut pas lancer GRUB si la variable de boot EFI correspondante n'existe pas (non créée ou supprimée) ou n'est pas prise en compte par un firmware buggé. Debian fait de même pour ne pas risquer d'écraser le chargeur d'un autre système qui serait déjà installé dans cet emplacement. Windows et d'autres distributions ont moins de scrupules et privilégient leur propre capacité à démarrer au détriment de celle des autres.

L'option --force-extra-removable de grub-install installe GRUB dans son emplacement normal et dans le chemin de support amovible. Comme @Dezix l'a mentionné, cette option est disponible lors de l'installation de Debian en mode expert. L'option --removable installe seulement GRUB dans le chemin de support amovible, mais dans le cas de Debian avec support du secure boot ce n'est pas la version normale de GRUB qui est installée mais une version qui semble prévue pour un CD (mais qui n'est pas utilisée dans les image ISO de Debian ) et avec laquelle j'ai eu des problèmes bizarres pour démarrer sur une machine donc je ne l'utilise pas.

Pour mar part j'installe systématiquement une copie de GRUB dans le chemin de support amovible car je ne fais pas confiance aux variables de boot EFI, leur gestion par les firmwares UEFI étant trop souvent buggée.

La question est : que se passait-il et pourquoi cette option a-telle résolu le problème ?
On pouvait voir avec efibootmgr qu'il n'y a pas de variable de boot EFI pour Windows ni Debian. Pourquoi le démarrage de Windows faisait disparaître ces variables, cela restera un mystère. La conséquence est que le firmware UEFI démarre avec le chemin de support amovible qui contient le chargeur de secours de Windows. --force-extra-removable a remplacé le chargeur de secours de Windows par shim+GRUB dans le chemin de support amovible. En bonus, shim, lorsqu'il est lancé depuis le chemin de support amovible, essaie de recréer des variables de boot EFI pour les chargeurs installés (qui ont un fichier boot*.csv). Il n'est pas clair pour moi si les variables de boot EFI sont encore supprimées lors du lancement de Windows puis recréées par shim lors du démarrage depuis le chemin de support amovible ou bien si elles ne sont plus supprimées depuis le remplacement du chargeur de Windows par GRUB dans le chemin de support amovible mais je ne vois pas pourquoi. J'ai aussi été supris par le retour de la variable de boot EFI pour Windows, je ne sais pas dire si c'est Windows lui-même ou shim qui l'a recréée.

Avertissement : comme le MBR pour l'amorçage BIOS, le chemin de support amovible est convoité par les systèmes d'exploitation et il est susceptible d'être écrasé par Windows lors d'une mise à jour. Pour l'éviter, il faudrait que Debian et Windows utilisent des partitions EFI distinctes. Mais cela ne suffit pas forcément : si la partition EFI de Windows est en premier, il est probable que c'est le chemin de support amovible de celle-ci que le firmware UEFI utilisera en cas de besoin.
DrPepere a écrit : 13 oct. 2022, 13:53 J'ai remarqué qu'il était marqué dans rescatux UEFI secure boot ON. Cela a-t-il quelque chose à voir?
Je ne pense pas, à moins que le secure boot influe sur la gestion des variables de boot EFI.
PascalHambourg
Contributeur
Contributeur
Messages : 876
Inscription : 05 août 2016, 20:25
Status : Hors-ligne

dezix a écrit : 14 oct. 2022, 11:42 j'avais d'abord installé Manjaro avant Debian (histoire de tester) que j'ai écrasé pour Debian ;
je comprends (pas bien) donc qu'il en reste une trace
L'explication est simple : la suppression d'un OS ne supprime pas les variables de boot EFI correspondantes.

Il semble que certains firmwares UEFI suppriment automatiquement les variables de boot EFI "invalides" (dont la cible n'existe pas), ce qui est problématique si on débranche le disque correspondant pour faire un test par exemple. Cependant cela ne s'applique pas si le chargeur d'amorçage du système supprimé n'est pas supprimé de la partition EFI (ou la partition EFI elle-même supprimée).
dezix a écrit : 14 oct. 2022, 11:42 La seule explication > cette entrée était présente à la livraison du matériel ?
Possible. Il a peut-être été testé avec Windows avant de t'être livré.
dezix a écrit : 14 oct. 2022, 11:42 puis-je sans risque supprimer :

Boot0000* Windows Boot Manager
Boot0005* Manjaro
Avec l'UEFI, rien n'est jamais sans risque. J'ai vu trop de bugs dans la gestion des variables de boot EFI, de leur non prise en compte au blocage total en passant par leur disparition ou réapparition inopinée.
Avatar de l’utilisateur
dezix
Membre hyper actif
Membre hyper actif
Messages : 3546
Inscription : 04 juin 2016, 14:50
Status : Hors-ligne

Un GRAND MERCI à PascalHambourg pour toutes ces précisions,
il y a de quoi méditer un moment pour les assimiler .

:good:

Pour ma part, je vais conserver les choses en l'état vue que tout fonctionne parfaitement.

:006:
**Simple Utilisateur** -- Debian stable - XFCE
Répondre