Généralités
Legacy Mode = Compatibility Support Module (CSM) = BIOS Mode . Utilisé pour qu’un système UEFI se comporte comme un BIOS traditionnel.
Pour savoir si l’on a bien booté en mode efi :
Sous Linux : dmesg | grep -i EFI ne renverra presque rien si l’on est en mode BIOS, mais plein d’infos (gestion mémoire etc) si on est en mode efi.
Sous Windows, il suffit de se repérer à la table de partition du disque système : il ne peut booter en mode BIOS que sur disque MBR, et en mode EFI que sur disque GPT.
À une certaine époque, fdisk ne gèrait pas les disques GPT. Aujourd’hui oui. gdisk les gère aussi, et permet un certain nombre d’actions dessus.
Les tables de partition GPT sont dupliquées ; en début ET en fin de disque. Pour cette raison, dumper un disque vers un disque plus grand ne fonctionne plus, car la table de secours ne sera pas correctement placée. Il faut copier la table de partition (sudo sgdisk /dev/sdX -R /dev/sdY pour copier la table de sdX VERS sdY), puis dumper chacune des partitions une à une.
Une table de partition GPT contient une zone réservée habituellement au MBR, avec plusieurs états possibles : cette zone MBR peut-être en protective (non utilisée, montre une seule grosse fausse partition de max 2To), en hybrid (une pseudo-table MBR devant concorder avec la table gpt sur 4 partitions) ou en MBR-only (c’est nativement un disque MBR). Le rôle de cette zone est d’éviter la modification/création d’une table MBR par des outils ne connaissant pas le GPT.
gdisk peut (ré)écrire une table hybrid-MBR pour qu’elle concorde avec l’état actuel de la table GPT. L’utilisation d’un hybrid-MBR est toutefois un hack étant aujourd’hui plutôt déconseillé.
On peut voir l’état de ce mbr avec l’outil gdisk :
sudo gdisk -l /dev/sdX
gparted gère sans problème les disques GPT, sauf dans le cas d’un disque en Hybrid-MBR. Les modifications seraient dans ce cas faites uniquement sur la pseudo-table mbr, sans tenir compte de la gpt, et donc de l’agencement réel des partitions, ce qui risque très probablement de casser toute la table. (edit : probablement plus vrai aujourd’hui)
Lors de la création d’une table de partition, va être créé un “Disk identifier” (sous forme d’UUID pour du GPT, et de 8 caractères hexadécimaux pour du MBR). Cet identifiant est purement logiciel.
Flags, types de partition
Une table de partition GPT associe à chaque partition un type, qui permet de donner une indication sur le rôle de la partition. Ce type est un UUID, qui se traduit en une appellation. Un fdisk -l affiche le type de chaque partition existante. On peut voir la liste complète des types de partition avec fdisk /dev/sdX puis l.
La partition sera accessible, même si le type ne concorde pas avec le formatage. Toutefois, certains types peuvent ne pas apparaître dans l’explorateur, et nécessiter un montage à la main (par exemple esp).
Sous GParted, un certain nombre de ces types de partition sont représentés par des drapeaux (flags). Par exemple,
- le drapeau “esp” (ou “boot”) équivalent à un type de partition EFI System Partition
- le drapeau “bios_grub” équivaut à un type “BIOS boot”
- le drapeau “diag” équivaut à “Windows recovery environment”
Lors du formatage vers certains systèmes de fichiers (par exemple ext4 ou ntfs), GParted assigne automatiquement le type “évident” à la partition (par exemple “Linux filesystem” ou “Microsoft basic data”).
Certains drapeaux sont toutefois indépendants du type ; par exemple “hidden” et “legacy_boot”.
Il y’a une explication de nombreux drapeaux ici.
Démarrage
L’UEFI ne peut démarrer un périphérique (disque dur, clé usb etc) qu’à partir d’une partition en fat32, nommée “EFI System Partition” (ESP). Typiquement, cette partition sera labellisée “efi”. Cette partition doit avoir le flag “boot” dans GParted (et le flag “esp” si la table de partition est GPT).
Le chemin par défaut où l’UEFI va chercher un bootloader (exécutable EFI) est ${ESP}/boot/BOOT${ARCH}.efi , typiquement /efi/boot/BOOTX64.efi. Si l’exécutable est ailleurs, on peut aller le chercher à la main lors du choix de boot (bien que ceci dépende de l’implémentation de l’implémentation sur la carte-mère).
L’UEFI supporte aussi l’enregistrement d’entrées de démarrage au sein-même de l’UEFI. Ceci permet d’avoir plusieurs bootloaders en parallèle, avec un chemin et un nom associés. Par exemple ${ESP}/Microsoft\bootmgrfw.efi (Windows Boot Manager) et ${ESP}/debian/grubx64.efi (debian). Ces entrées peuvent se visualiser et se gérer sous Linux avec la commande efibootmgr. Si définies, elles sont prioritaires sur le chemin par défaut.
Les CD et DVD sont bootables en UEFI via le format ElTorito, comme les BIOS auparavant.
Les disques au format MBR sont bootables aussi sans problème par un système UEFI, tant que la partition à booter est en fat32. La limitation de Windows qui ne peut booter en UEFI que sur GPT vient de Windows et non de la norme UEFI.
À l’inverse, les disques GPT peuvent être démarrés sur un système BIOS. Si GRUB est utilisé, il a besoin d’une partition dédiée (1Mo, non formatée) avec le flag “bios_grub”. Ceci lui permet de stocker les infos qui sont habituellement stockées dans un espace libre de la MBR (qui est ici utilisé par la table de partition GPT elle-même). Sans quoi la commande grub-install /dev/sdX renverra une erreur de “listes de blocs”. Une fois utilisée, cette partition apparaîtra avec le système de fichiers “grub2 core.img”.
Dans ce cas, la partition ESP ainsi que les flags “boot” et “esp” ne sont pas nécessaires. Ils peuvent toutefois être positionnés, pour faciliter une migration future vers un système EFI. Ceci nécessitera toutefois le remplacement du paquet grub-pc par le paquet grub-efi.
La plupart des UEFI sont de nature 64 bits, mais certains (souvent des PCs assez bas-de-gamme) ont un EFI uniquement en 32 bits. Ceci n’empêche pas le chargement d’un système en 64 bits, mais l’exécutable EFI (grub-efi, syslinux-efi etc) doit être en 32 bits.