Le titre que nous donnons à cette section est un rien ambigu. Car "démarrer par le réseau", cela peut avoir plusieurs sens. Soit celui d'initier la séquence de démarrage par le réseau, c'est-à-dire de réveiller à distance l'ordinateur, soit celui d'aller chercher ailleurs qu'en local un des éléments du processus --- les informations sur l'OS à charger, et/ou le noyau, et/ou des modules, et/ou le système de fichiers racine.
Dans le premier cas, pour que cela soit tout simplement possible, il y a certains pré-requis matériels (car le "réveil" du poste n'est possible que si celui-ci n'est qu'en partie endormi : si le courant est complètement coupé, vous n'êtes pas près de le ressusciter à distance...). Pour plus de renseignements sur le Wake On Lan, vous pouvez consulter la documentation disponible, entre autres le wol-mini-howto, ainsi qu'une page de Bonald Becker, sur le site de la société qu'il dirige : http://scyld.com/expert/wake-on-lan.html.
Dans le deuxième cas (qui peut être une conséquence d'un réveil provoqué par WOL...), suivant les éléments que l'on souhaite récupérer, le gestionnaire d'amorçage peut être concerné ou pas.
S'il s'agit de trouver, sur le réseau, des informations sur le système d'exploitation à charger, le gestionnaire d'amorçage est directement concerné.
Si c'est le système de fichiers racine, et seulement lui, qui doit être accédé par le noyau via le réseau --- cas de nfsroot ---, le gestionnaire d'amorçage n'est pas impliqué. Si par contre, c'est soit le noyau, soit au moins l'un des modules, soit le système de fichiers qui doit être téléchargé, il faut que le gestionnaire d'amorçage soit capable de le faire.
Or, capable de le faire, le GRUB l'est...
Le GRUB, dans les précédentes sections, accédait à différentes mémoires permanentes (disques) en utilisant les interfaces normalisées mises à disposition par le BIOS --- les services de l'interruption 13h pour ne pas la nommer.
Pour accéder au réseau, il n'est aujourd'hui pas possible de s'appuyer sur le BIOS : il faut donc des pilotes de périphériques. Ce sont ceux du projet libre etherboot qui, comme son nom l'indique, se destine à l'amorçage des cartes réseau Ethernet, plus précisément à la génération d'images destinées au gravage des [EE]PROM.
Le support pour la bonne carte doit être ajouté lors de la compilation du GRUB, qui n'inclut aucun support avec les options par défaut.
Mais, si vous vous en souvenez, dans notre exemple de compilation, nous avons inclus l'intégralité des cartes PCI supportées. L'avantage ? Pas en taille, puisque la dimension du stage2 s'en ressent forcément. Mais en flexibilité : la détection des périphériques ethernet PCI est incluse, ce qui permet de détecter une carte ethernet PCI installée, et de faire en sorte que le pilote idoine soit utilisé par défaut pour les accès par le réseau. Avec le GRUB ainsi compilé, vous pouvez donc démarrer par le réseau n'importe quelle machine équipée d'un des modèles PCI supportés. Ce n'est quand même pas mal !
Le gestionnaire d'amorçage, placé sur une disquette ou sur la PROM/EPROM/EEPROM d'une carte réseau, doit pouvoir piloter la carte, afin de récupérer par le réseau les éléments manquants.
En règle générale, le processus démarre par l'initialisation de la carte, suivie d'une crise existentielle de la machine, qui se met à bramer sur le réseau en agitant son adresse MAC (dans le cadre d'une carte ethernet) afin d'obtenir son adresse IP, et celles des serveurs à contacter par la suite. Cette première phase se fait via RARP, BOOTP ou DHCP. Les éléments obtenus, le protocole de transfert de fichiers le plus léger, à savoir TFTP, est utilisé pour récupérer les différents éléments.
Une fois les informations récupérées, la procédure est la même : il s'agit de charger un noyau, de lui communiquer les paramètres idoines, de lui mettre éventuellement à disposition un système de fichiers racine en mémoire, et de lui passer la main.
Pour plus d'informations, consultez les pages d' etherboot.
Nous supposons que le GRUB a été compilé conformément à notre exemple --- nous nous focalisons sur les cartes PCI, mais cela fonctionne également avec l'ISA, modulo la détection automatique...
La première chose à faire, c'est de provoquer la reconnaissance du
périphérique afin de pouvoir disposer d'un accès au réseau. La
commande à utiliser est bootp (dhcp est un simple alias) :
GRUB> bootp Found Realtek 8029 at 0xe800, ROM address 0x0 Probing...[Realtek 8029] NE2000 base 0xe800, addr xx:xx:xx:xx:xx:xx Address: 192.168.1.33 Netmask: 255.255.255.224 Server: 192.168.1.2 Gateway: 192.168.1.1
Bien entendu, les informations obtenues le sont parce qu'un serveur bootp/dhcp a été configuré et est accessible sur le réseau. Sinon, la station orpheline va brailler dans le vide...
Si un tel serveur est accessible et qu'il fonctionne, mais que le GRUB envoie des trames sans obtenir aucune réponse, trois sources de problème sont possibles :
A partir du moment où la requête a généré une réponse, un
nouveau périphérique est utilisable : (nd) mis pour Network
Device. La syntaxe est la même que pour les (hd|fd), mais il ne sera
pas possible d'utiliser la complétion, tout simplement parce que la
récupération des fichiers se fait via le protocole tftp, et qu'il
n'est pas possible d'explorer le répertoire distant.
La procédure est alors semblable aux autres types de périphériques à mémoire permanente :
kernel (nd)/var/tftpboot/boot/vmLinuz-2.4.12 root=...
La question qui vient à l'esprit --- si-si. Hein ? Non, toujours pas ? Hum...--- est la suivante : les protocoles BOOTP/DHCP sont prévus pour délivrer les informations nécessaires au démarrage. Toutes ces informations ne sont pas affichées dans l'exemple que nous avons donné (en particulier le nom du fichier de démarrage), mais au moins sont-elles disponibles sous forme de variables d'environnement de telle manière que quelque chose comme :
bootp kernel (nd)$filename
fonctionne ? Euh, non. Cela existera sans doute un jour, mais comme il y a quelques décisions à prendre sur l'architecture avant d'implémenter un langage de script un peu complet le bricolage est interdit pour l'instant.
Mais il y a une alternative.
On peut demander au GRUB de récupérer automatiquement un fichier sur
le serveur qui puisse lui servir de menu. Cela se fait via l'option
150 mise en place par ce type d'instruction à rajouter dans
/etc/dhcpd.conf :
option option-150 "/var/tftpboot/boot/grub.menu"
où, bien évidemment, le nom du fichier menu est libre mais doit correspondre à un fichier téléchargeable via tftp.
Dès lors, la simple instruction :
bootp --with-configfile
va initialiser le périphérique et récupérer le fichier menu défini sur le serveur. Il suffit donc de tenir à jour en un endroit (sur le serveur) un menu proposant les diverses alternatives pour offrir ces possibilités au client.
Autre avantage, vous pouvez obliger tout client à ne proposer que les options de démarrage définies dans ce fichier menu centralisé, qui peut varier en fonction des heures de la journée. Par exemple, imaginons une salle utilisée pour des cours, à certaines heures, et comme salle libre service à d'autres, avec ce type de procédé vous pouvez imposer le système à charger et avoir la maîtrise de ce qui tourne, à l'heure H, sur les différents postes.
Supposons que vous possédiez des postes sans mémoire permanente locale (ce qu'on appelle en franglais des stations diskless). Ces postes sont équipés d'une carte Ethernet munie d'une [EE]PROM, mémoire dans laquelle a été gravé un programme d'amorçage, de type PXE ou Etherboot. Vous pouvez parfaitement faire charger le GRUB en guise "d'OS" par ces programmes, afin de disposer des différentes possibilités offertes par celui-ci.
Par contre, comme il s'agit de charger un autre programme (le GRUB) il faut que le format (l'en-tête) de ce programme soit conforme à ce qui est attendu par le programme d'amorçage. C'est pour cela que vous pouvez configurer la compilation afin de générer les images PXE ou MBI (pour Etherboot) qu'il sera possible de faire charger par ces programmes d'amorçage.
L'option de configuration est --enable-diskless, qui ne sert
qu'à générer ces images, et n'est pas nécessaire à une utilisation
du réseau.