| Le royaume de Eric Buist >> Informatique >> Quelques-unes de mes recherches personnelles | ||
| Me contacter | Plan du site | |
| << Capture de contenu depuis Internet | GRUB et l'UEFI: peuvent-ils être réunis? | Capture vidéo de l'écran >> |
La première chose dont je me suis rendu compte quand j'ai voulu installer Linux sur mon nouvel ordinateur, le Drake, c'est à quel point je me suis tiré une balle dans le pied en installant Windows 7 de sorte qu'il démarre de façon native par rapport à l'UEFI. À cause de ça, je devais installer Linux aussi en mode UEFI de sorte que le gestionnaire d'amorçage GRUB puisse me permettre de choisir entre Windows et Linux au démarrage. Bien que les versions récentes de Linux prennent l'UEFI en charge en théorie, il en va tout autrement en pratique. Il suffit de chercher GRUB UEFI sous Google pour tomber sur des cinquantaines de posts de forums relatant d'insolubles problèmes d'installation qui réussissent mais de systèmes refusant de démarrer! Plusieurs affirment que GRUB2 est bogué et ne permet pas un démarrage correct en mode UEFI sur certaines machines. C'est peut-être vrai, peut-être pas, car il y a très peu d'indices au-delà de cela. Peu de gens semblent savoir ce qui se passe exactement et pouvoir établir des diagnostics précis. La seule page qui m'a vraiment aidé est le guide d'installation de rEFInd! Il me semble donc utile sur cette page de comparer le processus d'amorçage BIOS avec celui de l'UEFI et dresser une liste d'obstacles à franchir pour que GRUB puisse enfin démarrer en UEFI sur, espérons-le, la majorité des systèmes.
Dans le bon vieux temps, lorsque l'ordinateur démarrait, le processeur se trouvait dans ce qu'on appelle le mode réel. Ce mode exécute seulement un sous-ensemble primitif d'instructions sur 16 bits et ne permet l'accès qu'à un méga-octet de mémoire. C'est dans ce mode que s'exécutait le vénérable MS-DOS des années 1980. L'environnement de pré-amorçage était le BIOS et s'exécutait entièrement en mode réel.
Le rôle du BIOS était d'effectuer des tests de base et d'appliquer une séquence linéaire de recherche afin de trouver un périphérique sur lequel un premier secteur de 512 octets pouvait être lu (sans tenir compte de sa structure interne) et exécuté en mémoire comme un programme, encore en mode réel. Ce secteur d'amorçage devait alors soit démarrer le système d'exploitation, soit indiquer au BIOS de passer la main au prochain périphérique de la séquence. Habituellement, ce programme primitif est écrit en assembleur.
Ce premier secteur, qu'on appelle master boot record (MBR), localise habituellement une zone du disque dur appelée partition sur laquelle un autre secteur d'amorçage se trouve. Encore une fois, très peu d'hypothèses sont faites sur la structure interne du disque, à l'exception du premier secteur qui doit contenir une table de partitions dans le format MBR. Le code dans le premier secteur d'une partition, par contre, s'appuie sur sa structure pour amorcer un système d'exploitation. Ce dernier demande au processeur de passer en mode protégé qui permet d'accéder à toute la mémoire de la machine et peut exécuter des instructions sur 32 et même 64 bits.
Lorsque Linux est installé sur un tel système, le programme d'installation remplace le secteur d'amorçage par un code démarrant une application simple permettant de choisir quel système démarrer. C'est cela qu'on appelle le gestionnaire d'amorçage. Autrefois, on utilisait LILO pour cela, mais la plupart des distributions courantes se servent de GRUB. Le gestionnaire d'amorçage va s'occuper de charger et démarrer le noyau dans le cas de Linux, ou simplement passer le contrôle au premier secteur d'une partition désignée dans le cas de Windows.
C'est simple, relativement efficace mais pas très flexible et propice aux erreurs. Combien de fois Windows, pendant sa réinstallation, a-t-il effacé GRUB en remplaçant le secteur d'amorçage par le sien? Combien de fois ai-je constaté que le système pouvait démarrer depuis un disque dur externe mais pas d'un CD branché dans un lecteur DVD USB? Et que dire des ordinateurs qui, même en 2010, ne peuvent toujours pas s'amorcer depuis une clé USB? Ce sont toutes des limitations causées par le BIOS qui doit demeurer très simpliste afin de tenir dans un simple méga-octet de mémoire.
La MBR impose elle aussi son lot de limitations. Elle n'autorise que quatre partitions primaires sur le disque. Il est certes possible de créer une partition étendue permettant d'accueillir autant de partitions logiques que nécessaire, mais seules les partitions primaires peuvent être rendues amorçables. Pire encore, la MBR limite la taille d'un d'une partition à 2 terra-octets. C'est gros direz-vous, mais des disques de plus de 2 terra-octets sont maintenant disponibles.
Avec l'UEFI, les choses se passent de façon très différente. D'abord, tout l'environnement de pré-amorçage s'exécute en mode protégé. Cela signifie que le microprogramme de départ n'a plus à être si primitif que ça. Il peut initialiser une pile de gestion USB, la prise en charge du réseau et surtout accéder à des systèmes de fichiers. Ainsi, l'environnement de pré-amorçage est un système d'exploitation miniature. Il ne prend pas en charge le multitâches, mais il peut exécuter des applications compilées en C/C++, pas seulement en assembleur comme dans le bon vieux temps. Il existe un shell EFI qui permet véritablement d'exécuter des commandes et des scripts, de quoi faire frétiller le geek qui sommeille en vous. L'UEFI permet aussi la construction d'applications de configuration plus élaborées, avec un affichage graphique, prise en charge de la souris et plus d'options d'amorçage qu'avec le BIOS.
L'amorçage UEFI se passe donc de façon plus flexible. Plutôt que simplement lister des périphériques, le microprogramme examine leur contenu à la recherche d'exécutables de type UEFI et offre un point d'amorçage pour chacun de ces exécutables.
Chaque système d'exploitation peut alors fournir son propre exécutable UEFI qui effectue l'amorçage, avec la possibilité de s'exécuter en mode protégé, afficher du contenu à l'écran de façon indépendante du matériel, interagir au besoin avec l'usager, puis enfin, espérons-le en tout cas, charger le système d'exploitation proprement dit et lui passer le contrôle total!
Que la version UEFI de GRUB soit boguée ne sera éventuellement plus un problème, car il est possible de compiler les noyaux de Linux de sorte à les transformer en véritables applications UEFI. L'environnement de pré-amorçcage peut alors directement passer le contrôle au noyau de Linux! Que fait-on alors pour passer le contrôle à un autre système d'exploitation que Linux? Eh bien on utilise les options offertes par la carte mère, souvent très limitées, ou on installe un gestionnaire d'amorçage indépendant comme rEFInd. C'est simplement une autre application UEFI qui va utiliser toute la puissance de l'environnement de pré-amorçage pour offrir un menu permettant à l'usager de choisir vers quelle appliaction UEFI passer le contrôle. Il me faudra éventuellement vérifier cela, mais d'après ce que j'ai compris, le gestionnaire d'amorçage intégré dans le microprogramme de la carte mère et ceux offerts séparément accèdent aux mêmes interfaces, si bien qu'ils disposent des mêmes options d'amorçage en interne. Ce qu'ils exposent à l'usager varie bien entendu d'un gestionnaire à l'autre; tous ne sont pas égaux. En général, rEFInd est beaucoup plus polyvalent que ce qui vient avec la carte mère.
Que fait-on des vieux systèmes d'exploitation non compatibles avec l'UEFI? Eh bien l'environnement de pré-amorçage dispose d'un module de compatibilité permettant de repasser en mode réel et passer le contrôle à un secteur d'amorçage comme avant. À ce point, l'UEFI s'efface complètement, permettant au système d'exploitation de voir la machine comme si elle possédait un BIOS tout à fait ordinaire. Pour cette raison, si j'avais installé Linux en mode BIOS plutôt que UEFI, GRUB n'aurait pas permis d'amorcer Windows en UEFI. Il aurait alors fallu tout réinstaller en mode BIOS pour pouvoir démarrer tous les systèmes depuis GRUB, ou installer GRUB sur la partition où Linux se trouve (pas la MBR) et utiliser rEFInd pour permettre de choisir entre Windows et Linux. Le même problème se produit avec Chameleon, nécessaire pour charger Mac OS X, et pour le moment il n'y a aucune solution, car je n'ai pu trouver aucune version UEFI de Chameleon, le logiciel s'installe dans la MBR et rEFInd ne peut pas amorcer une MBR, seulement une partition.
Le gros problème avec tout ça, c'est que toutes les implémentations de l'UEFI ne sont pas égales. Elles ne répertorient pas toutes de la même façon la liste des applications UEFI vers lesquelles donner le contrôle. En gros, les règles suivantes s'appliquent:
Pour pimenter les choses encore un peu, l'utilisateur peut paramétriser l'amorçage! Il est possible d'interdire le démarrage en mode BIOS, celui en mode UEFI, de donner priorité à un système plutôt qu'un autre, etc. Certaines cartes mères comme la mienne permettent, à l'appui d'une touche comme F8, d'outrepasser la cible d'amorçage par défaut pour un démarrage donné, d'autres pas.
Eh bien, les raisons sont multiples! En voici quelques-unes auxquelles je peux penser, mais il pourrait y en avoir d'autres.
Bref, ce n'est pas très beau, mais c'est temporaire. Éventuellement, ces problèmes seront corrigés et, je l'espère, tous les noyaux seront compilés en tant qu'appliactions UEFI de sorte que le chargement et la gestion d'amorçage seront des procédés bien distincts et interchangeables.