UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

Arbiel · Le 08/08/2022, à 20:45

Bonsoir à tous

Pour les disques gpt, Gparted propose les drapeaux esp, boot, bios_grub et legacy_boot qui semblent tous les 4 liés aux modes de démarrage UEFI et BIOS hérité.

Très clairement, le drapeau esp indique la partition dans laquelle est enregistré grub pour un démarrage en mode UEFI.

Le contenu de cette partition appelle quelques explications.

J'ai installé Ubuntu sur un disque absolument vierge. Les fichiers qui en sont résultés sont localisés dans les répertoires /EFI/BOOT (BOOTX64.EFI, fbx64.efi, mmx64.efi) et /EFI/ubuntu (BOOTX64.CSV, grub.cfg, grubx64.efi, mmx64.efi, shimx64.efi). J'ai constaté que sont égales les signatures md5sum de /EFI/BOOT/BOOTX64.EFI et de /EFI/ubuntu/shimx64.efi (78415fb8fb9b909f8029858113f1335f), de même que celles de /EFI/BOOT/mmx64.efi et de /EFI/ubuntu/mmx64.efi (dc3c47be2f78a78e5e57d097ae6c5c84). Pourquoi faut-il que ces fichiers soient dupliqués dans deux répertoires différents sous deux noms éventuellement différents ? Il n'est pas évident de comprendre pourquoi les fichiers Grub n'ont pas été directement enregistrés dans /EFI/BOOT.

On comprend bien la réplication des fichiers plutôt que la création de liens symboliques ou physiques par le fait que les systèmes fat ne disposent probablement pas d'une telle option.

De même on peut supposer que le fichier /EFI/ubuntu/grub.cfg est un simple renvoi vers le fichier éponyme de /boot/grub pour répondre au besoin d'enregistrement de /boot/grub/grubenv. L'introduction dans grub de l'accès en écriture au système fat pour cette seule utilité paraît en effet superfétatoire.

Les trois autres drapeaux boot, bios_grub et legacy_boot correspondent vraisemblablement à diverses configurations dérivées du BIOS, pour un démarrage dit en BIOS hérité.

Quels sont les modes opératoires correspondants ?

Arbiel

Nasman · Le 09/08/2022, à 11:09

Je pense que gparted permet - outre le formatage - de spécifier les drapeaux utilisables par les différents OS.
Ces drapeaux ne doivent pas fonctionner de la même manière selon que le disque soit de type msdos ou gpt.

En mode msdos, on aura l'identifiant boot (l'étoile dans le fdisk) ou la valeur hexa 0x80 dans les infos des tables des partitions (adresse 1be, 1ce, 1de ou 1ee). Ce drapeau boot est nécessaire pour Windows (boot legacy) mais inutile pour Linux.
Le drapeau esp doit exister en boot EFI sur partitions msdos (cas très spécial) et je pense que c'est l'identifiant "efi" qui remplace l'identifiant de la partition fat32.

Avec une table gpt, les informations de boot (comme bios_grub) sont indiquées dans les types des partitions des tables gpt (LBA=2 à 33).

Il serait intéressant de tester ces différents drapeaux et de regarder l'incidence sur le contenu des tables des partitions (avec un éditeur hexa - ou dd)

Arbiel · Le 09/08/2022, à 19:43

Bonsoir Nasman

J'ai trouvé quelques informations sur la page du manuel Gparted de la FSF. Malheureusement ces informations sont très générales et ne répondent pas précisément à mes interrogations.

Autant que je puisse comprendre, le module CSM de l'UEFI peut lancer un chargeur de système (grub pour ce qui nous concerne) par inspection du secteur 0 du disque.

Soit il s'agit d'un MBR valide (disque msdos), le lancement s'effectue sur la base de la présence du drapeau boot sur l'une des partitions et sur la routine enregistrée dans les 440 premiers octets de ce MBR.

Soit il s'agit d'un MBR invalide (disque gpt), le lancement devrait se faire de manière très analogue : lecture des secteurs à partir du secteur 2 pour recherche de l'existence d'un drapeau spécifique sur une des partitions, puis passage du contrôle comme dans le cas précédent à la même routine contenue dans les 440 premiers octets du secteur 0.

La différence entre ces deux modes se limite à l'inspection des partitions, qui ne se trouvent pas à la même adresse.

Il semblerait logique que le drapeau gpt en question soit nommé boot. Ce pourrait aussi être legacy_boot.

On peut se demander ce que signifie les autres drapeaux, et surtout le drapeau bios_grub quand on réalise que l'UEFI n'a pas lieu de connaître la nature du chargeur de système.

Cordialement

Arbiel

Nasman · Le 10/08/2022, à 07:13

Le drapeau bios_grub sert à permettre le démarrage en mode bios (ou legacy) sur un disque gpt.

Dans un disque gpt, le 1er secteur (LBA=0) est le mbr protector qui contient une pseudo table msdos qui indique une unique partition de type ee commençant à la LBA=1. Cette partition fait soit la taille du disque, soit le maximum accessible pour une table msdos (codage des emplacement et des tailles sur 4 octets).
Le deuxième secteur (LBA=1) contient l'en-tête gpt.
Les secteurs suivants (LBA=2 à 33) contiennent les caractéristiques des 128 partitions possibles (4 par secteur), emplacement et taille codés sur 8 octets (--> gpt permet ainsi de dépasser la limite des 2 Tio).

Lors d'un boot en mode bios, le code du 1er secteur (mrb ou mbr protector) est chargé en mémoire vive (boot.img) puis le reste de core.img est chargé en mémoire vive. Cependant :
- avec un disque msdos la suite du code (diskboot.img) est à la LBA=1 et suivantes
- avec un disque gpt, ces secteurs sont déjà occupés (en-tête gpt à la LBA=1 et descriptifs des partitions aux LBA=2-33). Il faut donc une partition dédiée (sans système de fichier) pour y placer le code de core.img (en fait il y a le "chargeur diskboot.img et core.img). La partition avec le drapeau bios_grub sert à cela : boot legacy sur disque gpt.

Nota : cette partition peut être placée comme n'importe quelle partition, à partir de la LBA=2048 par défaut (alignement au Mio) mais elle peut aussi être placée entre la LBA=34 et LBA=2047 (zone inoccupée car placée entre la fin des descriptifs des partitions gpt et la première partition alignée au Mio.

Nota2 : une fois l'installation faite, l'emplacement de la partition bios_grub (ou de diskboot.img) est indiqué dans le mbr protector (ou le mbr) à l'offset 4c (de mémoire). Le drapeau n'est alors plus utile pour le boot.

Arbiel · Le 10/08/2022, à 20:32

Bonsoir Nasman

Nasman a écrit :

Nota2 : une fois l'installation faite, l'emplacement de la partition bios_grub (ou de diskboot.img) est indiqué dans le mbr protector (ou le mbr) à l'offset 4c (de mémoire). Le drapeau n'est alors plus utile pour le boot.

En es-tu certain?

La valeur enregistrée à l'offset 4c (ou autre) peut être n'importe quelle valeur. Ne faut-il pas conserver le drapeau bios_grub dans le descripteur de la partition pour bien marquer qu'elle contient grub ?

Arbiel

Nasman · Le 11/08/2022, à 07:45

Dans le fonctionnement du code boot.img placé dans me mbr (ou mbr protector), il y a examen de la valeur située à l'offset 0x64. En général cette valeur vaut 0xff, ce qui signifie que le code à charger est dans le disque de boot. D'autres valeurs sont possible : 0x80 = 1er disque dur, 0x81 = deuxième disque dur...
Après des tests de l'existence de fonctions avancées du bios, le secteur dont l'adresse LBA est située à l'offset 0x5c (et non pas 4c) est chargé en mémoire vive (c'est le code de diskboot.img). Dans un disque msdos, cette adresse est la LBA=1, dans un disque gpt c'est l'adresse de boot_grub.
Lorsque ce code est exécuté, le reste de core.img est chargé en mémoire vive (grâce au chargeur diskboot.img).

Nota j'ai testé la possibilité de charger diskboot.img et core.img à partir d'un autre disque que celui de boot ou de changer l'emplacement du code de diskboot.img+core.img avec succès.

Il doit être possible de spécifier tous ces éléments en maitrisant les paramètres de grub-install

En ce qui concerne le drapeau, je pense qu'il est nécessaire pour les mises à jour de grub - même s'il ne sert plus pour un démarrage normal. Si la valeur située à l'offset 5c est modifiée sans que grub ne la gère correctement alors on peut avoir des problèmes.

Edit : code présent dans le mbr

Dernière modification par Nasman (Le 11/08/2022, à 07:47)

Arbiel · Le 15/08/2022, à 17:56

Bonsoir Nasman

Je te remercie pour ces informations détaillées.

En cherchant des informations sur l'UEFI, je suis tombé sur la page qui indique

La compatibilité avec BIOS Legacy n’est toutefois qu’une solution transitoire. À l’heure actuelle, Intel demande aux fabricants de PC de ne plus implémenter de CSM. Ce processus doit être progressivement supprimé pour réduire le code UEFI-BIOS et baisser ainsi les coûts pour les tests de matériel.

Il ne s'agit que d'une information qui n'a rien d'officiel, mais qui sous-entend que le chargement en mode BIOS hérité est destiné à disparaître des nouveaux ordinateurs dans les quelques années à venir.

Cordialement

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 08/08/2022, à 20:45

UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

#2 Le 09/08/2022, à 11:09

Re : UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

#3 Le 09/08/2022, à 19:43

Re : UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

#4 Le 10/08/2022, à 07:13

Re : UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

#5 Le 10/08/2022, à 20:32

Re : UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

#6 Le 11/08/2022, à 07:45

Re : UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

#7 Le 15/08/2022, à 17:56

Re : UEFI, BIOS hérité, esp, boot, bios_grub, legacy_boot : mode opératoire

Pied de page des forums