Page 1 sur 1

bootloader, GPT, Grub, efibootmgr

Publié : 02 jan 2019, 23:09
par adrien050356
Bonjour,

un petit mélange de question concernant le boot pour y voir plus claire. J'ai recemment eu des soucies (casi résolues) avec mon pc, et ceci m'a ammené à me poser des questions sur le fonctionnement du boot.

- Si on considère un system UEFI/GPT, au démérrage l'UEFI initialise le support utile et charge ensuite en RAM le bootloader de l'OS à lancer qu'il va chercher dans /boot/efi/EFI/... . Puis, le bootloader charge le Kernel.
Mais à quoi sert la partition GPT la dedans ? lorsqu'on était encore au MBR, c'est lui qui chargait le bootloader en RAM, mais ici ce n'est pas le cas, alors je ne vois pas à quoi sert la partition GPT.

- Avait vous quelque détails sur le "bootloader séquence 1 et 2"? Je comprends bien que la première sequence, contenant peu de code, et là pour charger un code plus gros (le bootloader) qui, lui, va charger le Kernel de l'OS. Mais comment tout ceci s'enchaine ?

- efibootmgr permet voir/changer l'ordre de boot de l'UEFI. dans le cas ou le Bootloader est Grub par exemple, en quoi efibootmgr est utile puis-ce que c'est avec Grub que l'on choisit l'action à effectuer ?
Sur mon pc j'ai Manjaro et Windows10 en dual boot, au démarrage j'ai Grub qui me permet de chosir entre les deux. Ainsi, pourquoi l'ordre d'éfinie avec efibootmgr est important ?

Voilà pour les questions, c'est déjà bien. J'ai essayé de faire des recherches, mais tout n'est pas encore claire.

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 05:58
par lemust83
Bonjour.
Adrien050356 a écrit :Mais à quoi sert la partition GPT la dedans ? lorsqu'on était encore au MBR, c'est lui qui chargait le bootloader en RAM,
En fait, GPT (Guide Partition Table) n'est pas une partition, mais une table de partitions. C'est une sorte de sommaire qui décrit le partitionnement du disque. Sa taille dépasserait les 512 Octets d'un MBR.
L'une d'elle sera une partition ESP ou EFI formatée en Fat32 (héritage Intel/W$) qui contiendra le firmware de la carte mère lequel ne pourrait non plus tenir dans un MBR.
Ce firmware est à lui seul un quasi système d'exploitation qui sera en charge d'activer le Bootloader. En théorie, le nombre de partitions sur un disque en GPT n'est pas limité et les volumes peuvent dépasser 2To qui est la limite absolu avec un disque contenant une Table en DOS.
Dans ce cas, le nombre de partitions physiques est seulement de 4 au maximum + le Master Boot Record de 512 octets dans lequel se logera le bootloader.
Les besoins des matériels récents sont de plus en plus exigeants en terme de place et d'accès aux disques et la technologie en 32 bits du MBR ne répond plus.
En théorie, on pourrait se passer de Grub, mais les spécificités de chaque distro, notamment le micro-code nécessaire qui doit être chargé avant le kernel sur Arch/Manjaro, le rend quasiment incontournable.
Extraits du wiki d'Arch sur l'EFI:
UEFI est conçu pour supprimer le besoin d'un chargeur de démarrage intermédiaire tel que GRUB . Si votre carte mère dispose d'une bonne implémentation UEFI, il est possible d'incorporer les paramètres du noyau dans une entrée de démarrage UEFI et de permettre à la carte mère de démarrer Arch directement. Vous pouvez utiliser efibootmgr ou UEFI Shell v2 pour modifier les entrées de démarrage de votre carte mère.
Sauf que les firmwares UEFI ne sont pas implémentés de manière cohérente entre les fabricants, et mieux vaut donner un adressage vers Grub .
GRUB est le chargeur de démarrage tandis que efibootmgr est utilisé par le script d'installation de GRUB pour écrire les entrées de démarrage dans la NVRAM.
Voilà pour les généralités :sourire:
Il y a aussi cette page encore en anglois (Messire... :lol: ) qui explique assez bien la séquence de démarrage de système UEFI.

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 12:07
par adrien050356
le firmware de la carte mère est contenue dans l'ESP ?! C'est pas le meilleurs moyen de le perdre en cas de soucie ou de formatage ?! en fait, je pensais qu'il était contenue dans la NVRAM.

Concernant GRUB, c'est donc lui qui fait office de "bootloader général" pour remplacer la "non adaptabilité" de l'UEFI si j'ai bien compris ?
En revanche, GRUB fait partie de manjaro en fait, non ? donc lancer GRUB, revient à charger le bootloader de manjaro pour avoir accès au différent choix de boot ?

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 13:14
par lemust83
Quand on dit "contient le firmware", il faut comprendre "une copie d 'une partie du firmware" qui lui reste bel et bien gravé dans les chipsets de la carte mère. Lors de la mise sous tension, le firmware procède à un premier check puis inscrit les composants dans la partition ESP. Tant qu'on ne reformate pas l'ESP, ces composant restent .
Voici une arborescence de mon ESP:

$ tree /boot/efi
/boot/efi
└── EFI
    ├── boot
    │   ├── bootx64.efi
    │   └── grubx64.efi
    └── Manjaro
        └── grubx64.efi
boot-x64 est une partie du firmware qui interagit avec grub.
J'ai trouvé cette cette page en français qui décrit bien la séquence d'initialisation.

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 14:38
par obelix1502
Tiens !!
Je n'ai pas tout à fait la même chose que toi :

/boot/efi
└── EFI
    ├── boot
    │   └── bootx64.efi
    └── Manjaro
        └── grubx64.efi

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 21:57
par adrien050356
J'en ais évidemment encore moins que vous puis ce que j'avais formaté ma partition EFI.

adrien@adrien ~ % tree /boot/efi
/boot/efi
└── EFI
    └── manjaro
        └── grubx64.efi
lemust83 a écrit : il y a 5 ans Quand on dit "contient le firmware", il faut comprendre "une copie d 'une partie du firmware" qui lui reste bel et bien gravé dans les chipsets de la carte mère. Lors de la mise sous tension, le firmware procède à un premier check puis inscrit les composants dans la partition ESP. Tant qu'on ne reformate pas l'ESP, ces composant restent .
Est-ce que ca veut dire que je peux récuperer cette copie (i.e bootx64.efi) à partir du chipset ?
je suis pas sûr d'avoir saisit le "le firmware procède à un premier check puis inscrit les composants dans la partition ESP"
lemust83 a écrit : il y a 5 ans boot-x64 est une partie du firmware qui interagit avec grub.
J'ai trouvé cette cette page en français qui décrit bien la séquence d'initialisation.
J'ai personnellement trouvé cette page qui m'a bien aidé. En anglois toujours :wink:

Autre chose. Je me rend compte que je n'ai jamais eu (dans mes souvenir en tout cas) d'interface UEFI à proprement parlé sur mon PC. C'est à dire cette interface super friendly avec la prise en compte de la souris. J'ai toujours eus quelque chose que j'ai toujours appelé le BIOS puis ce que ca en à toutes les ressemblances. Comment ça ce fait ?

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 22:04
par stephane
alors de mon côté

tree /boot/efi

/boot/efi
└── EFI
    ├── Boot
    │   └── BOOTX64.EFI
    └── manjaro
        └── grubx64.efi
c'est bien le grubx64.efi de manjaro qui démarre , cependant s'il y a un pb , on fait une copie
lors de l'install USB ( donc EFI de la clé USB ) , en cas de secours ( grubx64.efi non trouvé ou chemin incorrect)

attention d'autres distributions peuvent écraser la partie Bootx64.efi

sudo cp /boot/grub/x86_64-efi/core.efi /boot/efi/EFI/boot/bootx64.efi
le Bios n'est que la gestion du démarrage , et les fabricants de carte-mere n'ont pas tout a fait jouer le jeu ,
car ils ont voulu poursuivre ce qu’ils faisaient avant ( en bios Pur ) dans EFI + CSM infame ( a eviter a tout prix )

par exemple si vous voyez : EFI [Legacy] avec inxi -Fxxx cela signifie
attendu de démarrer par EFI , mais une des options m’oblige a démarrer en Legacy ( USB , autre valeur ) cad en mode bios et non EFI car les fabricants ne font plus le moindre effort pour EFI OSI linux mais uniquement pour Microsoft

intel a annoncer qu'à partir de 2020 , il n'y aura plus de Bios ou mode CSM , que EFI v3.0

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 22:55
par adrien050356
stephane a écrit : il y a 5 ans attention d'autres distributions peuvent écraser la partie Bootx64.efi

sudo cp /boot/grub/x86_64-efi/core.efi /boot/efi/EFI/boot/bootx64.efi
C'est pratique dites-moi. Je l'ai rajouté de mon côté. J'imagine que, puis-ce que bootx64.efi et lancé par défault par l'UEFI si aucun bootloader n'est trouvé, il n'est pas nécéssaire de l'ajouter a la NVRAM avec efibootmgr ?

adrien@adrien /boot/efi/EFI/boot % tree /boot/efi 
/boot/efi
└── EFI
    ├── boot
    │   └── bootx64.efi
    └── manjaro
        └── grubx64.efi
stephane a écrit : il y a 5 ans le Bios n'est que la gestion du démarrage , et les fabricants de carte-mere n'ont pas tout a fait jouer le jeu ,
car ils ont voulu poursuivre ce qu’ils faisaient avant ( en bios Pur ) dans EFI + CSM infame ( a eviter a tout prix )

par exemple si vous voyez : EFI [Legacy] avec inxi -Fxxx cela signifie
attendu de démarrer par EFI , mais une des options m’oblige a démarrer en Legacy ( USB , autre valeur ) cad en mode bios et non EFI car les fabricants ne font plus le moindre effort pour EFI OSI linux mais uniquement pour Microsoft
Ce qui veut dire que je boot en mode BIOS ? d'où mon interface toute nul façon BIOS ? pourtant mon OS est bien installé façon UEFI. J'ais surement pas saisi ce que tu voulais dire je pense :gsourire:

Re: bootloader, GPT, Grub, efibootmgr

Publié : 03 jan 2019, 23:24
par stephane
le Bios pour ma part est le gestionnaire de démarrage du fabricant
initialement qui démarrait sur MBR
et avec EFI , ils ont ajouté ces différents modes ( EFI Secure ou Legacy ( windows) , EFI Others , EFI CSM )

si tu démarre strictement avec Windows tu est obligé d'être verrouillé ,
et tu ne peux pas facilement accéder aux données de efibootmgr

su ma config si je laisse USb Mass Storage actif je démarre en EFI[legacy] ,
essaye ensuite d'accéder aux données efibootmgr , c'est déjà verrouillé par le Bios au démarrage de la machine.

j'ai du revoir toutes les options pour avoir EFI et la clé USB soit reconnu en EFI
on a une seule partiton Boot ( prioritaire ) , un seul ESP a cause de cela
et donc la possibilité offerte d'avoir plusieurs ESP sur differents disques pose probleme de ce fait

j'ai déjà essayé d'avoir plusieurs DE manjaro sur d'autres disques en EFI pour chacun , la derniere install
casse le flag boot précédent et update ne se fait que pour le disque avec ESP et pas les autres ,
de plus manjaro ( et quasi toutes les autres distributions ) ne gèrent pas en variable dans Grub chaque saveur DE ,
donc au mieux le dernier écrase les précédents

--> tu as abouti a un sac de noeud et cela a fini par casser sur le Grub - boot ( --> reinstall Grub Efi ... )

origine de ce choix unique : issu de la logique du bios qui ne possède qu'un tableau de point d'entrée obligant a avoir un ordre de démarrage prioritaire vis a vis du tableau et non de ce qu'il y a sur chaque disque
( plus le problème de longueur du nom affiché qui reprends devant EFI: .... )

ce n'est pas la même chose par exemple sur EFI Apple ( similaire a Refind )
il installe sur chaque disque /boot/efi , et au démarrage , il va scanner chaque disque pour te proposer sur lequel un os X de démarrage est présent ( cad par disque en lisant a chaque fois le /boot/efi )