| Page suivante Page précédente Table des matières | GRUB-HOWTO: Présentation de la bête |
Le GNU GRUB est, comme son nom l'indique, un projet GNU. Sa page internet est http://www.gnu.org/software/grub/grub.en.html. Le programme a une histoire, des développeurs occasionnels et des responsables permanents : Gordon Matzigkeit et OKUJI Yoshinori.
Le GRUB possède de nombreux avantages par rapport à LILO, ne serait-ce que la possibilité d'utiliser un shell : le GRUB est un mini-système d'exploitation. Le programme, par exemple installé sur une disquette, permet donc sans noyau disponible sur celle-ci d'aller en chercher un, et de lui passer la main.
Qui plus est, le GRUB ne reconnaît pas uniquement une description en terme d'accès de bas niveau aux périphériques (accès aux blocs), mais les systèmes de fichiers minix, ext2, ffs, fat et reiserfs (en attendant ntfs et befs et d'autres). Elle est pas belle la vie ?
Les explications qui suivent sont un mini-HOWTO couvrant le GRUB et sa logique, de la compilation à l'utilisation de base, avec fichiers d'exemples (le luxe quoi...).
Le GRUB a été défini, dès l'origine, comme un outil dont l'objectif est d'être un gestionnaire d'amorçage universel, puissant et flexible.
La plupart des autres gestionnaire d'amorçage sont des solutions ad hoc attachées à un OS particulier, et qui ne permettent de démarrer d'autres systèmes d'exploitation qu'en repassant la main au gestionnaire d'amorçage "maison". L'opération est le chaînage d'amorceurs (en anglais : chainloading) : le gestionnaire d'amorçage charge en mémoire le gestionnaire d'amorçage du système invoqué ; il ne démarre donc pas directement le système d'exploitation.
Devoir installer une myriade de solutions particulières afin, finalement, de réaliser une tâche dont le principe est identique : charger en mémoire un noyau, d'éventuels fichiers supplémentaires, puis transmettre au noyau les paramètres idoines, avant de lui passer la main, n'est peut-être pas la meilleure solution. Une spécification est en cours d'élaboration : le multiboot standard, qui est implémentée entre autres par le HURD et dans une partie du projet flux. Mais pour la majorité des autres, il faut encore faire sans. Le démarrage particulier de Linux est donc pris en compte nativement, et suivant les versions du GRUB et les changements apportés au processus de démarrage dans les *BSD, le GRUB supporte leur démarrage en natif, ou via le chainloading... Pour Windows ? Chainloading uniquement. Vous en doutiez ?
Une grande part des manières de démarrer, sur une architecture Intel pour l'instant, sont supportées : sur disques locaux (disquettes, disques IDE ou SCSI), ou par réseau. Si le BIOS le permet, le GRUB s'affranchit des limites du 1024ème cylindre. Mais le GRUB reconnaît aussi les systèmes de fichiers minix, ext2, FFS, FAT et ReiserFS, ce qui lui permet d'accéder aux fichiers et donc aux noyaux par leur nom. Vous pouvez donc déplacer physiquement un noyau au sein d'un répertoire sans avoir besoin de réinstaller le GRUB : si le nom du noyau n'a pas changé (le nom complet s'entend : répertoire compris), le GRUB, y accédant par ce nom c'est-à-dire par le système de fichiers sera capable de le retrouver.
Le GRUB dispose d'un mini-shell autorisant l'exploitation de toutes les commandes internes. A l'aide d'une disquette contenant le GRUB, vous pouvez démarrer n'importe quel poste dès lors que vous parvenez à retrouver, sur l'un des disques, le noyau. Et si le poste n'a pas de disque ? C'est qu'il doit démarrer par le réseau, et cela, le GRUB sait le faire aussi.
Le GRUB proprement dit correspond en fait au stage2. C'est ce
stage2 qui offre l'intégralité des fonctionnalités de ce mini-OS. Mais
il s'agit d'arriver à le charger en mémoire. Sur architecture Intel, pour ce
faire, il n'y a guère qu'une solution : passer par un programme de
512 octets au plus, situé soit sur le MBR, soit dans le secteur de boot d'une
partition. Comme il s'agit de la toute première pièce de l'édifice, son nom
est le stage1.
Ce stage1, vu ses limites, ne reconnaît bien évidemment pas les systèmes de fichiers, et ne sait accéder à la suite que par la liste physique des blocs à charger.
Quel est le rôle des *stage1_5, alors ? De se situer, si possible, entre le stage1 et le stage2 afin de permettre de charger le stage2 en accédant par le système de fichiers. Si vous observez le résultat de la compilation, vous trouverez les *stage1_5 correspondant aux systèmes de fichiers supportés.
Il existe par contre une contrainte, lorsqu'on prend les options d'installation par défaut : le stage1_5 doit être logé (c'est le grub ou le grub-shell qui s'en occupent) dans les blocs suivant immédiatement le secteur de boot, dont éventuellement le MBR. En règle générale, un certain nombre de secteurs suivant immédiatement le MBR sont inutilisés (ou utilisés par certaines applications sur certain OS pour stocker des données que l'on veut cacher à l'utilisateur), et un stage1_5 pourra s'y placer. Sur une disquette, ne disposant pas de MBR, cet espace n'existe pas. Donc, sur une disquette, le *stage1_5 correspondant au système de fichier dans lequel est situé le stage2 ne sera pas installé automatiquement (une erreur non fatale sera signalée).
Conclusion ? Le stage1 accédera au stage2 par la liste de blocs. Corollaire : si le stage2 est physiquement déplacé, le stage1 ne pourra pas le charger correctement.
Par contre, dans tous les cas, le stage2 sera capable, lui, d'accéder aux systèmes de fichiers (s'il a été compilé avec le support des systèmes de fichiers --- ce qui est le cas par défaut).
Le GRUB proprement dit est donc le stage2. Quid de ce qui s'appelle le grub, que l'on trouve dans le sous-répertoire du même nom ? Il s'agit du grub-shell, une émulation du shell grub fonctionnant sous Unix. Ce n'est pas le gestionnaire d'amorçage, mais un shell permettant d'utiliser certaines fonctionnalités du stage2, en particulier pour l'installer, mais pas forcément n'importe où : faire directement l'installation sur le disque dur, depuis un système Unix ne permettant pas d'identifier aisément quels sont les disques vus par le BIOS, qui plus est avec des systèmes de fichiers montés, est particulièrement dangereux. Cela n'est pas conseillé, et la bonne méthode (TM) est décrite plus loin.
grub-install est un script Bourne shell destiné à simplifier
l'installation de l'amorceur (sans que l'utilisateur ait à utiliser
directement le grub-shell sous Unix --- l'appel est fait par le script).
Bon. Oui mais non. Il ne sera pas couvert dans le présent HOWTO. J'ai mes têtes ;) L'installation est plus simple AMHA via le grub-shell pour une disquette, et impose de connaître un minimum de commandes qui serviront un jour. C'est plus simple et plus pédagogique. Qui plus est, ce qui a été dit précédemment reste vrai : installer le grub sur un disque depuis un système d'exploitation n'est pas sûr. Fermez le ban !
grub-md5-crypt est aussi un script invoquant le grub-shell afin de
coder via md5 une chaîne de caractère (en l'occurrence un candidat au mot de
passe). Utilisation triviale.
mbchk, pour multiboot check, est un programme
destiné à vérifier qu'un noyau est conforme aux spécifications multiboot.
Comme nous l'avons évoqué plus haut, qu'un noyau s'y conforme serait, à
l'avenir, une bonne chose. Mais le cas est rare actuellement --- par exemple
les noyaux Linux ne s'y conforment pas ---, ce qui n'empêchera pas le GRUB
de trouver le moyen de les charger (nativement, ou via le "chainloading").
| Page suivante Page précédente Table des matières |