Dokuwiki

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
Tuto Ubuntu : http://doc.ubuntu-fr.org/netboot

====== 1. Introduction ======

Le netboot est l'art de démarrer un équipement sur un logiciel qui n'est pas présent sur un support physique local (disque dur, ROM, clé USB, etc). Nous allons décrire une technique s'appuyant sur des protocoles standardards basés sur Ip nommée **PXE**.

Il peut exister plusieurs raison d'utiliser le //netboot//:
  * les équipements n'ont pas de support physique pour démarrer: le cas des //thin clients// ou //diskless stations//
  * les équipements ont un support non modifiable pour démarrer: cas des ROMs des appareils dits embarqués
  * vous n'avez pas d'accès physique à l'équipement pour lui ajouter un support de boot (CD-ROM, clé, disque, etc)
  * vous voulez massivement démarrer des équipements sur un même logiciel (sans dupliquer les supports physiques et donc faciliter les mises à jour)

====== 2. Séquence de boot ======

La séquence de boot sur une machine utilise souvent les mêmes procédures :

===== BIOS =====

C'est le premier logiciel qui démarre sur la machine, et son rôle est de vérifier le bon fonctionnement des éléments essentiels (CPU, RAM) et enfin de fournir une interface minimaliste pour accéder au périphérique contenant le logiciel à démarrer. Il doit donc savoir dialoguer à minima avec des contrôleurs USB, ATA, SATA, etc. En ce sens le BIOS est déjà un mini-OS, et c'est d'ailleurs la raison d'être de http://linuxbios.org/Welcome_to_LinuxBIOS LinuxBIOS.

===== Bootloader =====

Il s'agit du premier logiciel chargé par le BIOS à partir du media de boot désigné. Les conventions exigent en général de très petits programmes (un BIOS PC ne charge que les premiers 512 octets du media de boot) qui ont donc un rôle simpliste (sélection d'une image de boot et de paramètres). Exemples : ISOLINUX, Lilo, Grub.

Le rôle principal du bootloader consiste à charger en mémoire une ou deux images (le noyau et optionnellement une image de système de fichier - le //initrd//), puis de lancer l'exécution du noyau. Pour ce faire, il s'appuie d'une part sur le BIOS qui sait accéder au media de boot et d'autre part sur sa propre connaissance de la structure du media pour charger ses images (par exemple, obtenir le fichier /boot/vmlinuz sur une structure //ext2//).

===== Noyau =====

Une fois le noyau démarré, celui-ci utilisera alors ses propres pilotes pour accéder aux différents media, y compris celui de boot. C'est pour cela qu'on peut observer la fameuse erreur //PANIC: could not mount root file system// alors que le noyau a de toute évidence été bien chargé depuis ce même périphérique: la première phase a été exécutée avec succès par le BIOS qui possédait le bon pilote, mais la seconde a échoué car le noyau ne possédait pas le pilote ad hoc.


====== 3. PXE/bootp ======

Les mécanismes **PXE** et **bootp** sont souvent présentés ensembles : bootp est en fait peu utilisé et c'est souvent PXE qui est utilisé voire désigné à travers le terme bootp. Toutefois ces deux mécanismes utilisent des protocoles différents.

La séquence de boot utilisée par le mécanisme PXE est en tout point similaire à celle qui vient d'être décrite, sauf qu'elle doit prendre en compte la configuration réseau de la machine et une convention pour charger le bootloader.

===== BIOS =====

Pour que PXE fonctionne, il faut tout d'abord que le BIOS puisse dialoguer avec l'interface réseau concernée. C'est de plus en plus le cas pour les interfaces embarquées sur les carte mères, mais ce fut longtemps le rôle d'une extension du BIOS qui devait être fournie par la carte réseau - celle-ci étant souvent matérialisée par une ROM supplémentaire qu'il fallait enficher sur la carte de l'interface réseau.

**Note**: cette notion de ROM est encore utilisée pour maintenir des "pilotes de BIOS" pour cartes réseau, cf http://rom-o-matic.net/ Rom-o-Matic.

===== BIOS/DHCP =====

Ensuite, un BIOS conforme PXE va tenter de configurer l'interface via le protocole DHCP. Il obtiendra ainsi en retour les éléments de configuration, plus des extensions PXE (en gras):
  * adresse, masque de sous-réseau
  * passerelle
  * **nom d'un serveur TFTP**
  * **chemin du bootloader disponible via TFTP**

En pratique, ceci se traduit par une configuration de ce type pour un serveur ISC DHCP :
  host bob {
  hardware ethernet 00:1a:ae:10:36:af; # Reconnaît l'interface de l'équipement
  fixed-address 10.0.1.42; # Assigne une adresse...
  option subnet-mask 255.255.255.0; # ... et un masque
  option routers 10.0.1.1; # Passerelle par défaut
  next-server 10.0.1.2; # Le serveur TFTP
  filename "/tftpboot/pxelinux.0"; # Le bootloader, conforme PXE
  }

===== BIOS/TFTP =====

Le protocole **TFTP** est un FTP simplifié basé sur le protocole UDP et dont le client peut être implémentée de façon très compacte (il est notamment stateless), mais il est très peu résilient aux erreurs.

Par convention le chemin du bootloader commence par ///tftpboot/// et comme TFTP est rarement //chrootable// il est présent dans ce même chemin absolu sur le serveur.

===== Bootloader =====

Si le BIOS charge spontanément l'image demandée (champs //filename// et //next-server// du DHCP), le bootloader une fois exécuté pourra opter de réutiliser ce mécanisme pour charger d'autres fichiers (sa configuration, le noyau, une image de système de fichier [//initrd//], etc).

===== Noyau =====

Le problème reste identique: une fois le noyau démarré, celui-ci devra posséder le pilote pour son media principal. Si le noyau désire continuer via le réseau, par exemple avec NFS pour son système racine, il devra posséder le pilote de l'interface réseau sur laquelle il a booté **et** la configurer - donc en particulier redéfinir l'adresse IP, le masque, la passerelle, etc (via une nouvelle requête DHCP ou statiquement en paramètres du noyau).