Guide pratique de l'amorçage sur réseau et des systèmes de fichiers racine exotiques

Version française du Network-boot-HOWTO

Logilab S.A.

Adaptation française : Nicolas Jadot

Version : 0.3.fr.1.0

2004-09-09

Historique des versions
Version 0.3.fr.1.02004-09-09NJ
Première version française
Version 0.32002-04-28bej
Insertion de retours d'expérience, ainsi que des liens vers différents projets
Version 0.2.22001-12-08dcm
Placé sous licence GFDL
Version 0.2.12001-05-21logilab
Bibliographie terminée
Version 0.22001-05-19bej
Plusieurs amélioration et ajout des retours d'expérience de Ken Yap
Version 0.1.12001-04-09logilab
Premier brouillon public
Version 0.12000-12-09bej
Brouillon initial

Résumé

Ce document explique comment mettre rapidement en œuvre un serveur sous linux pouvant fournir tout ce qui est nécessaire à un client linux pour démarrer sur un réseau IP. Il inclut des éléments extraits du Diskless-HOWTO, du Diskless-root-NFS-HOWTO, de la documentation du noyau linux, des pages du projet etherboot et de linux terminal server project, ainsi que de l'expérience personnelle de l'auteur, acquise lorsqu'il travaillait pour Logilab. Eventuellement, ce document peut rendre obsolètes le Diskless-HOWTO et le Diskless-root-NFS-HOWTO. Veuillez noter également que vous trouverez d'autres informations utiles dans le guide pratique "De la mise sous tension à la ligne de commande bash" et dans le Thin-Client-HOWTO, ainsi que sur la page écrite par Claus-Justus Heine sur le basculement entre pages NFS.


Table des matières

1. Introduction
1.1. De quoi parlons-nous ?
1.2. Remerciements
1.3. Plaidoyer pour les stations sans disque
1.4. Exigences
1.5. Références et documentation associée
1.6. Retour d'expérience
1.7. Mentions légales
2. Panorama du démarrage sans disque
2.1. Récupérer les paramètres IP
2.2. Charger le noyau
2.3. Monter le système de fichiers racine
2.4. Terminer la procédure de démarrage
3. Construire le noyau
3.1. Racine sur un disque virtuel
4. Configuration des démons
4.1. Démon NFS
4.2. Démon BOOTP
4.3. TFTP
5. Configuration des clients, construction du système de fichiers racine
5.1. Créer les premiers fichiers et répertoires
5.2. Les répertoires /var et /etc
5.3. Derniers détails
5.4. Essais...
5.5. Une erreur !
6. Différentes manières de récupérer le noyau
6.1. Interfaces réseaux à capacités bootp ou DHCP
6.2. Noyau sur disquette ou disque dur local
6.3. Chargeur de démarrage sans noyau sur un support local
6.4. Créer les ROM des clients
6.5. CD-ROM local
7. Comment créer des stations MS-Windows sans disque ?
8. Problèmes, trucs, difficultés et liens utiles
8.1. Traiter les fichiers spécifiques aux stations de manière transparente
8.2. Réduire l'occupation de la mémoire des stations
8.3. Partition swap sur NFS
8.4. Echange sur un périphérique réseau en mode bloc (NBD - Network Block Device)
8.5. Se débarasser des messages d'erreur au sujet de /etc/mtab ou de répertoires non démontés lors de la séquence d'arrêt;
8.6. Installer de nouveaux paquetages sur les stations
A. Composants mémoire persistants
B. Déterminer la capacité et la vitesse d'une EPROM à destination d'un adaptateur réseau
C. Fournisseurs de stations sans disques
Références

Logilab a soutenu la rédaction de ce guide. Reportez-vous à son site pour les nouvelles versions de ce document. Je remercie également les administrateurs et les développeurs de etherboot, netboot, plume et linux terminal server project, qui ont réellement rendu possible le démarrage sur réseau d'une station linux.

J'adresse des remerciements particuliers à Ken Yap, membre du projet etherboot, dont les commentaires ont beaucoup aidé à la qualité de ce guide

Je remercie également Jerome Warnier, développeur principal du projet plume, Pierre Mondié, Kyle Bateman, Peter T. Breuer, Charles Howes et Thomas Marteau pour leurs commentaires et leurs contributions.

Les ordinateurs sans disque deviendront de plus en plus populaires d'ici quelques années. Leur succès ira de paire avec l'arrivée sur le marché de cartes réseau haut débit à bas prix. Une carte offrant un débit de 100 Mégabit (taux de transfert de 12,5 Mo par seconde) est aujourd'hui répandue et, dans un ou deux ans, des cartes offrant des débits de 1000 MBit (125 Mo par seconde) deviendront accessibles et s'imposeront comme le standard.

Dans un futur proche, les fabricants d'écrans y incluront le processeur, la carte réseau et la mémoire afin d'en faire des ordinateurs sans disque. Ce qui permettra d'éliminer le boitier et d'économiser de la place. L'écran sera muni des prises pour clavier, souris, réseau et alimentation électrique.

Les bénéfices à attendre d'une machine sans disque sont les suivants :

La chose la plus importante dont il faut disposer pour pouvoir amorçer un ordinateur par le réseau est d'avoir un équipement permettant à la station d'exécuter un gestionnaire d'amorçage , qui chargera le noyau sur le serveur et lançera son exécution. Une autre solution est d'utiliser un noyau local, sur un périphérique quelconque, qui montera un système de fichier racine situé sur le serveur. Il existe de multiples solutions : inscrire les instructions de démarrage sur une EPROM, utiliser une carte réseau supportant BOOTP/DHCP, utiliser une disquette, un disque dur de petite taille ou un CD-ROM pour charger le noyau. Notez que quelques fabricants vendent des ordinateurs en mesure de démarrer sur le réseau : certaines stations Sun implantent le protocole BOOTP.

Les autres caractéristiques matérielles dépendent de l'usage que vous envisagez : sur certains sites, toutes les application s'exécutent du côté serveur, qui doit alors être performant, mais les stations peuvent être très légères : selon l'utilisation, un 80486 dôté de 16 Mo de mémoire vive peut suffire. A l'opposé, si les applications s'exécutent sur le client, les exigences matérielles dépendent totalement de la nature de ces applications. Dans ce cas, un serveur léger peut suffire. Un 80486 avec 32 Mo de mémoire sera suffisant pour un nombre réduit de postes clients, mais davantage de mémoire sera nécessaire pour des installations plus vastes, comptant plusieurs centaines ou milliers de stations. Notez que le processeur du serveur n'est pas crucial pour de telles installations.

Cette documentation a été écrite à l'intention d'administrateurs systèmes expérimentés, rompus à la pratique de linux, comme l'utilisation de grep, sed et awk, la programmation shell, les processus et les scripts de démarrage, la compilation du noyau et la configuration d'un serveur NFS. Avoir l'expérience du passage d'arguments au noyau aidera. Des informations sur ces sujets peuvent être trouvées dans les pages de manuel de grep, sed, awk, dans les pages de manuel et d'info du shell bash, dans les guides pratiques "Disquettes d'amorçage", "De la mise sous tension à la ligne de commande bash", "Noyau linux", "BootParam-HOWTO" , dans les pages de manuel de bootparam et de rdev, dans le guide pratique de NFS et sur la page de manuel d'exports.

Il existe de multiples sources d'information concernant le démarrage sur réseau mais, et c'est pourquoi j'ai écrit ce guide, aucune ne décrit toutes les possibilités existantes, et la plupart sont spécifiques à une méthode. Celle qui m'a été la plus utile est la documentation fournie par linux terminal server project, bien que je n'ai pas utilisé le paquetage qu'elle recommande et que j'ai choisi de décrire ici comment procéder sans ces paquetages, car ils font le choix d'exécuter toutes les applications à distance sur le serveur. Des informations utiles sont également disponible sur la page du projet etherboot.

Enfin, vous pouvez trouver des informations utiles mais succintes dans l'arborescence des sources du noyau, dans le répertoire /usr/src/linux/Documentation, /usr/src/linux étant le répertoire où résident les sources du noyau.

Vous pensez qu'il est temps de passer aux choses sérieuses ? C'est parti.

En premier lieu, construire le noyau pour les clients. Je vous suggère d'effectuer cette opération sur le serveur, ce qui sera bien pratique pour l'installation des modules. Utilisez zImage pour réduire la taille du noyau. Incluez tout ce qui est nécessaire mais essayez d'utiliser autant de modules que possible car de nombreuses implantations clientes de BOOTP sont incapables de charger des noyaux volumineux (au moins sur les architectures Intel x86). Incluez le support d'iramdisk, du protocole NFS, de la racine sur NFS, le support de votre adaptateur réseau et celui de l'autoconfiguration IP par BOOTP ; n'utilisez pas de module pour ces fonctionnalités ! Enfin, si vous avez l'intention d'utiliser la même racine pour plusieurs clients, ajoutez le support du système de fichier ext2 ou autre, ainsi que le support des disques virtuels (un disque virtuel de 16 Mo conviendra sur la plupart des systèmes). Vous pouvez modifier les arguments du noyau comme à l'habitude (voir le guide pratique "BootPrompt-HOWTO" à ce sujet), mais vous pourrez toujours le faire plus tard.

Là, si vous envisagez de faire usage de BOOTP, copiez le noyau zImage sur le serveur. Nous supposerons qu'il réside dans le répertoire /tftpboot, que son nom est zImage, que le nom de l'image créée pour BOOTP à partir de zImage est kernel, et que la racine NFS est sous /nfsroot.

Saisissez les commandes suivantes sur le serveur (le paquetage mknbi doit être installé) :

# cd /tftpboot
# chmod 0555 zImage
# chown root:root zImage
# mknbi-linux zImage --output=kernel
--rootdir=/nfsroot

Si vous utilisez des EPROM LanWorks, saisissez également les commandes suivantes (l'utilitaire imggen est nécessaire) :

# mv -f kernel tmpkernel
# imggen -a tmpkernle kernel
# rm -f tmpkernel

Le noyau est près à être utilisé avec BOOTP, DHCP ou sur une ROM. Ces opérations ne sont bien entendu pas nécessaires si vous comptez vous servir d'un support local au client.

Il est possible d'utiliser un disque virtuel pour le système de fichiers racine. Dans ce cas, la commande permettant de modifier l'image binaire du noyau quelque peu différente. Si vous choisissez cette option, il vous faudra permettre le support du disque virtuel initial (initrd), et vous pourrez peut-être vous passer du support de NFS, ou le compiler en tant que module.

Il est temps de s'intéresser à ce qui se passe quand vous utilisez initrd. La documentation complète est disponible dans les sources du noyau dans le fichier Documentation/initrd.txt. Je dois vous prévenir que je n'ai jamais essayé :).

Quand initrd est activé, le gestionnaire de démarrage charge en premier le noyau et le disque virtuel initial en mémoire. Le disque virtuel est monté en lecture-écriture comme système de fichiers racine. Le noyau recherche un fichier nommé /linuxrc (un exécutable binaire ou un script commençant par #!). Quand /linuxrc se termine, la racine traditionnelle est montée sous /, et la séquence de démarrage normale est exécutée. Donc, pour permettre à la station de travailler entièrement sur le disque virtuel, il vous suffit de créer un lien de /linuxrc vers /sbin/init, ou d'écrire là un script exécutant toutes les actions que vous désirez, et d'arrêter l'ordinateur.

Une fois le noyau compilé, vous devez construire un système de fichiers racine pour votre installation. La méthode est expliquée dans la section "Configuration des clients, construction du système de fichiers racine". Je supposerai que cela est déjà fait et que la racine des clients est, temporairement, dans le répertoire /tmp/rootfs. Il faut maintenant créer l'image du disque virtuel. Une méthode simple est :

Ce qui a été noté plus haut concernant les EPROM LanWorks est également valable si vous utilisez initrd.

Maintenant, vous devez modifier l'image du noyau, comme expliqué plus haut, avec l'utilitaire mknbi-linux. La suite de commandes diffère peu (je suppose que l'image du noyau est /tftpboot/zImage et que l'image du disque virtuel est /tmp/initrd) :

# cd /tftpboot
# chmod 0555 zImage
# chown root:root zImage
# rdev zImage /dev/ram0
# mknbi-linux zImage --output=kernel
--rootdir=/dev/ram0 /tmp/initrd

Je supposerai que le paquetage bootpd est installé. Le fichier de configuration par défaut est /etc/bootptab, et sa syntaxe est décrite dans la page de manuel de bootptab. Créons ce fichier.

Lancez, en tant que root, votre éditeur favori. Vim. Si, si, c'est celui-là. Si ce n'est pas le cas, il doit le devenir. Maintenant, tapez les lignes suivantes (ce sont les attributs par défaut). Tous les attributs que vous définissez ici, et qui ne sont redéfinis dans aucune liste d'attributs spécifique à une machine, seront valables pour tous les clients :

       .default\
                :sm=votre masque de sous-réseau\
                :ds=adresse IP du serveur de noms \
                :ht=ethernet\
                :dn=nom de domaine\
                :gw=adresse IP de la passerelle\
                :sa=adresse IP du serveur TFTP\
                :bf=chemin d'accès à l'image du noyau\
                :rp=chemin d'accès à la racine\
                :hn
      

Bien entendu, tous ces paramètres ne sont pas indispensables, et dépendent de la configuration du réseau et de l'implémentation de BOOTP utilisée, mais cela fonctionnera dans la plupart des cas.

Maintenant, ajoutez une entrée pour chacun des clients de votre réseau. Une entrée se présente sous la forme :

        nom du client\
                :ha=adresse MAC du client\
                :ip=adresse IP du client
      

L'adresse MAC est l'adresse matérielle du client en hexadécimal, sans les ':'.

Voici un exemple de fichier /etc/bootptab :

              .default\
                      :sm=255.255.0.0\
                      :ds=192.168.0.2\
                      :ht=ethernet\
                      :dn=frtest.org\
                      :gw=192.168.0.1\
                      :sa=192.168.0.2\
                      :bf=/tftpboot/kernel\
                      :rp=/nfsroot\
                      :hn

              foo\
                      :ha=001122334455\
                      :ip=192.168.2.12

              bar\
                      :ha=00FFEEDDCCBB\
                      :ip=192.168.12.42\
                      :ds=192.168.2.42
      

Enfin, lancez le démon bootpd avec la commande bootpd -s (il est judicieux d'ajouter cette commande dans vos scripts de démarrage), ou ajoutez la ligne suivante à votre fichier /etc/inetd.conf :

        bootps dgram udp wait root /usr/sbin/tcpd bootpd -i -t 120
      

Si vous désirez tester le serveur BOOTP, ajoutez une entrée dans le fichier /etc/bootptab et utilisez le programme bootptest.

Fatigué ? Non, vous ne l'êtes pas. Souvenez-vous que vous êtes un héros. Ici commence la partie délicate. Nous allons (err... vous allez) construire la racine des clients. Ce ne devrait pas êtres très difficile, mais préparez vous à de nombreux essais et erreurs.

La méthode la plus simple pour créer le système de fichiers racine est d'utiliser un système de fichiers existant et de l'adapter aux besoins. Bien sûr, vous pouvez le construire à la main (comme au bon vieux temps) si cela vous dit :=), mais je n'expliquerai pas cela ici.

Tout d'abord, déplacez vous dans le futur répertoire racine de vos stations. Vous pouvez facilement créer le répertoire /home par la commande mkdir, ou en le copiant à partir d'où vous voulez (utilisez la commande cp -a pour effectuer une copie récursive préservant les propriétaires, groupes, liens symboliques et permissions). Même chose pour les répertoires /mnt, /root, /tmp (n'oubliez pas chmod 0 sur ce dernier, puisqu'il n'est qu'un point de montage du /tmp réel que nous utiliserons, car chaque station a besoin de son propre répertoire /tmp). Copiez les répertoires /bin, /sbin, /boot et /usr existant dans le futur répertoire racine (commande cp -a). Vous pouvez créer le répertoire /proc avec mkdir, et utiliser chmod 0 dessus. Notez que certaines applications ont besoin d'un accès en écriture sur le répertoire de leur utilisateur.

Le répertoire /lib peut être copié sans danger de n'importe où, mais vous devrez y installer les modules qui conviennent. Pour ce faire, utilisez les commandes suivantes (considérant que le noyau compilé pour les clients réside sur le serveur dans /usr/src/linux, et que la racine est dans /nfsroot) :

# cd /usr/src/linux
# make modules_install INSTALL_MOD_PATH=/nfsroot

N'oubliez pas de placer le fichier System.map dans le répertoire /nfsroot/boot. Un premier problème que nous aurons à résoudre est que, en fonction de votre configuration, le système peut essayer de lancer fsck sur la racine au démarrage. Impossible sans disque dur. La plupart des distributions omettrons fsck si un fichier fastboot est présent dans le répertoire racine. Aussi, tapez les commandes suivantes si vous ne comptez pas monter de disque dur :

# cd /nfsroot
# touch fastboot
# chmod 0 fastboot

Une autre méthode consiste à indiquer à fsck que la vérification d'un système de fichiers NFS réussit à chaque fois :

# cd /nfsroot/sbin
# ln -s ../bin/true fsck.nfs

Le répertoire /dev peut être copié d'un autre emplacement vers /nfsroot. Les permissions et les liens symboliques devant être préservés, utilisez la commande cp -a. Une autre solution est d'utiliser la fonctionnalité devfs des noyaux 2.2.x, qui réduit la consommation mémoire tout en augmentant les performances, mais le défaut de cette méthode est que tous les liens symboliques existant dans /dev seront perdus. Le point à garder à l'esprit est que chaque station a besoin de son propre répertoire /dev, aussi vous devrez le copier sur un disque virtuel si vous voulez avoir plusieurs clients et ne pas utiliser devfs.

Nous utiliserons des disques virtuels pour ces répertoires, chaque client devant avoir les siens propres. Mais nous en avons encore besoin au début pour créer leur structure standard. Notez que cela n'est pas nécessaire si vous n'avez qu'un seul client. Copiez donc ces répertoires (cp -a) dans /nfsroot. Vous pouvez alors faire un peu de ménage dans /var : vous pouvez effacer tout le contenu de /nfsroot/var/log et de /nfsroot/var/run. Vous pouvez probablement effacer également le contenu de /nfsroot/var/spool/mail si vous comptez exporter ce répertoire via NFS. Vous devrez enfin supprimer les fichiers contenant des informations spécifiques à la machine présents dans /nfsroot/etc pour les construire à la volée durant le processus de démarrage.

Les scripts de démarrage doivent être modifiés afin de pouvoir monter certaines parties de l'arborescence : le répertoire /dev si vous n'utilisez pas devfs, les répertoires /tmp, /var et /etc. Le code suivant effectue ces modifications :

        # cette partie uniquement si vous n'utilisez pas devfs
        mke2fs -q -i 1024 /dev/ram0 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram0 /dev
        # cette partie dans tous les cas
        mke2fs -q -i 1024 /dev/ram1 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram1 /tmp
        chmod 1777 /tmp
        cp -a /etc /tmp
        mke2fs -q -i 1024 /dev/ram2 16384
        mount -n -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram2 /etc
        find /tmp/etc -maxdepth 1 -exec cp -a '{}' /etc ';'
        mount -f -t ext2 -o rw,suid,dev,exec, \
            async,nocheck,remount /dev/ram2 /etc
        mount -f -o remount /
        cp -a /var /tmp
        mke2fs -q -i 1024 /dev/ram3 16384
        mount -t ext2 -o rw,suid,dev,exec, \
            async,nocheck /dev/ram3 /var
        find /tmp/var -maxdepth 1 -exec cp -a '{}' /var ';'
      

Dans le cas où vous aurez plus d'un seul client, vous devrez changer dynamiquement au démarrage certains fichiers contenus dans /etc : ceux contenant l'adresse IP et le nom d'hôte du client. Ces fichiers dépendent des distributions mais vous les retrouverez aisément avec grep. Contentez-vous de retirer de ces fichiers toutes les informations spécifiques à un client, et ajouter le code permettant la génération de ces informations lors du démarrage, mais uniquement une fois que le nouveau /etc a été monté sur le disque virtuel ! Ci-dessous une méthode permettant d'obtenir l'adresse IP et le nom d'hôte lors du démarrage (si bootpc est installé dans l'arborescence des stations) :

        IPADDR="$(bootpc | awk '/IPADDR/ \
                                {
                                  match($0,"[A-Za-z]+")
                                  s=substr($0,RSTART+RLENGTH)
                                  match(s,"[0-9.]+")
                                  print substr(s,RSTART,RLENGTH)
                                }
                               ')"

        HOST="$(bootpc | awk '/HOSTNAME/ \
                              {
                                match($0,"[A-Za-z]+")
                                s=substr($0,RSTART+RLENGTH)
                                match(s,"[A-Za-z0-9-]+")
                                print substr(s,RSTART,RLENGTH)
                              }')"

        DOMAIN="$(bootpc | awk '/DOMAIN/ \
                                {
                                  match($0,"[A-Za-z]+")
                                  s=substr($0,RSTART+RLENGTH)
                                  match(s,"[A-Za-z0-9-.]+")
                                  print substr(s,RSTART,RLENGTH)
                                }')"
      

C'est une solution compliquée mais je pense qu'elle fonctionne sur la plupart des sites. On peut trouver l'adresse IP grâce à la commande ifconfig et le nom d'hôte par la commande host mais cela n'est pas portable, car les sorties diffèrent entre les systèmes, en fonction de la distribution utilisée et du paramétrage local.

Là, le nom d'hôte pourra être déterminé avec la commande hostname $HOSTNAME. Une fois ceci fait, il est temps de générer à la volée les fichiers de configuration contenant l'adresse IP ou le nom d'hôte du client.

On peut maintenant passer aux réglages fins. Comme /var sera monté sur un disque virtuel (suaf si vous n'avez qu'un seul client), vous devrez sauvegarder les logs sur un serveur, si vous voulez les conserver. Une méthode pour ce faire consiste à supprimer le fichier /nfsroot/etc/syslog.conf et à le remplacer par le fichier suivant (man syslog.conf pour plus de détails) :

        *.*     /dev/tty12
        *.*     nom ou adresse IP du serveur contenant les logs
      

Avec cette méthode, le serveur de logs devra faire tourner syslogd avec l'option -r (reportez-vous à la page de manuel de syslogd).

Si vous utilisez logrotate et avez effectué les opérations précédentes, vous devrez remplacer le fichier de configuration de logrotate (/etc/logrotate.conf sur la plupart des machines) par un fichier vide :

        # rm -f /etc/logrotate.conf
        # touch /etc/logrotate.conf
      

Si vous n'en faites pas usage, contentez-vous de retirer les scripts de rotation des logs de la crontab et, tant que vous n'aurez pas de fichiers de log dans /var/log, placez exit 0 au début de vos scripts de rotation.

Retirez du fichier /nfsroot/etc/fstab toutes les références à des disques durs, lecteurs de disquettes ou CD-ROM qui sont absents de vos stations clientes. Ajoutez une entrée pour le répertoire /var/spool/mail, qui pourrait être exporté par le serveur par NFS ou par tout autre système de fichiers réseau. Vous pourrez vouloir également ajouter une entrée pour /home dans ce fichier.

Vous pouvez également mettre en commentaire les lignes exécutant newaliases, activant le swap, et exécutant depmod -a et également supprimer le fichier /nfsroot/etc/mtab. Retirez les commentaires des lignes de vos fichiers de démarrage concernant /fastboot, /fsckoptions, et /forecfsck. Retirez également ou mettez en commentaires toutes les lignes des scripts de démarrage qui tenteraient d'écrire sur le système de fichiers racine, à l'exception des accès en écriture réellement nécessaires, qui devraient tous être redirigés vers l'emplacement d'un ramdisk si vous utilisez plusieurs clients.

Nous avons parlé plus haut de la configuration du client et du serveur en vue des opérations s'exécutant une fois que le client a terminé la requête bootp, mais le premier soucis est que la plupart des ordinateur est incapable de fonctionner par défaut comme client bootp. Nous allons voir dans cette section comment résoudre ce problème.

De nombreuses cartes réseau comportent un slot permettant l'insertion d'une EPROM contenant du code BIOS additionnel. Cela permet d'ajouter, par exemple, des fonctionnalités bootp au BIOS. Pour ce faire, il convient tout d'abord de trouver comment activer la prise supportant l'EPROM. Il peut être nécessaire d'agir sur un cavalier ou d'utiliser un logiciel spécifique. Quelques cartes, telles la 905B de 3Com, disposent de branchements pour EEPROM, ce qui permet de modifier le logiciel embarqué dans l'EEPROM. En annexe, vous trouverez des informations sur les EPROM et sur les différents types de composant de mémoire.

Pour obtenir la liste des fabricants de brûleurs d'EPROM, reportez-vous au site Yahoo, dans le répertoire Economie->Entreprises->Matériel->Périphériques->Programmateurs ou reportez-vous au guide pratique Diskless-HOWTO, section Liste des fabricants de brûleurs d'EPROM.

Si vous choisissez de créer vos propres ROM, vous devrez y charger un logiciel bootp ou DHCP et alors, vous vous retrouverez dans la configuration d'une carte réseau possédant ces caractéristiques, tel que décrit plus haut.

Vous devrez également trouver la taille et la vitesse d'EPROM appropriés à votre adaptateur réseau. Des méthodes pour ce faire sont fournies en annexe, car les fabricants de cartes fournissent rarement ces informations.

Cette section a originellement été écrite par Hans de Goede () pour le guide pratique "Système de fichiers racine sur NFS". Je l'ai juste modifié dans la mesure nécessaire pour rendre compte des différences entre le présent document et le guide pratique "Système de fichiers racine sur NFS".

La majeure partie de ce qui est écrit ci-dessus est également valable pour le démarrage par CD-ROM. Pourquoi vouloir démarrer une machine depuis le lecteur de CD-ROM ? Le démarrage sur un CD-ROM est surtout intéressant pour des applications très spécifiques, comme un kiosque, une base de données de bibliothèque, un net-café, ou pour celui qui n'a pas de réseau ou de serveur pour permettre l'usage d'un système de fichiers racine sur réseau.

Maintenant que nous savons ce que nous voulons faire et comment, il est temps de réaliser une configuration test.

S'il vous faut davantage d'informations que celles fournies ci-dessous, référez-vous au guide pratique "Gravure de CD-ROM".

Comme MS-Windows n'apporte pas de support pour le démarrage sans disque, un simple tour d'horizon des solutions est présenté ici : la solution est d'utiliser un logiciel comme VMWare ou son alternative libre, plex86. Bien que plex86 semble avoir été abandonné, on peut encore démarrer certaines versions de MS-Windows en utilisant ce logiciel. Cela permet d'exécuter de manière transparente MS-Windows sur une machine linux.

Si vos stations ne dispose pas de suffisament de mémoire et n'ont pas de disques locaux, vous pouvez utiliser une partition d'échange sur NFS. Cependant, gardez à l'esprit que le code de cette fonctionnalité est encore en phase de développement et que son fonctionnement est généralement assez lent. La documentation complète de cette fonctionnalité est disponible à http://www.instmath.rwth-aachen.de/~heine/nfs-swap/.

La première chose à faire pour mettre en œuvre cette fonctionnalité est de modifier votre noyau (vous devez disposer de la version 2.2 ou supérieure). Téléchargez le modificatif à l'adresse fournie ci-dessus et déplacez vous dans le répertoire /usr/src/linux. On considère que le modificatif est dans /usr/src/patch. Utilisez la commande suivante :

        # cat ../patch | patch -p1 -l -s
      

Ceci fait, compilez votre noyau de manière habituelle en activant les options Partiton d'echange sur réseau (EXPERIMENTALE) et Partiton d'échange par NFS (EXPERIMENTALE).

Exportez alors un répertoire en lecture-écriture et avec l'option no_root_squash depuis le serveur NFS. Configurez les clients pour qu'ils montent ce répertoire quelque part (disons dans /mnt/swap). Il devra être monté avec des paramètres rsize et wsize inférieurs à la taille de page utilisée par le noyau (soit 4ko sur architecure Intel), sans quoi la machine risque de se trouver à cours de mémoire, pour cause de fragmentation ; reportez vous à la page de manuel de nfs pour les détails concernant les paramètres rsize et wsize. Pour créer une partition d'échange de 20Mo, utilisez les lignes de commande suivantes (à placer dans les scripts d'initialisation des stations clientes) :

        # dd if=/dev/zero of=/mnt/swap/swapfile bs=1k count=20480
	# mkswap /mnt/swap/swapfile
	# swapon /mnt/swap/swapfile
      

Bien entendu, ceci n'est valable que pour une seule machine, car si vous en disposez de plusieurs il vous faudra modifier les noms des fichiers et des répertoires, sans quoi toutes vos stations utiliseraient le même fichier d'échange...

Un mot encore sur les caractéristiques des partitions d'échange par NFS : en premier lieu le mécanisme est généralement lent, sauf à disposer d'interfaces réseau spécialement rapides. Cette possibilité n'a pas encore été beaucoup testée. Enfin, ce n'est pas sécurisé : n'importe qui sur le réseau est à même de lire les données transférées.

Bien que je n'ai jamais testé personnellement, j'ai eu des retours selon lesquels cette astuce fonctionne, du moins avec des noyaux récents.

Le principe général est le même qu'avec NFS. Le point positif est qu'il n'est pas nécessaire de modifier le code du noyau. Mais la plupart de ses caractéristiques s'appliquent également à cette méthode.

Pour créer un espace de swap de 20 Mo, vous devrez d'abord le créer sur le serveur, puis l'exporter vers le client, enfin, exécuter mkswap sur le fichier. Notez que la commande mkswap doit être exécutée sur le serveur, car mkswap fait usage d'appels système non supportés par NBD. De plus, cette commande doit être exécutée après que le serveur ait exporté le fichier, car les données contenues dans celui-ci risqueraient d'être détruite au moment où le serveur commence l'exportation. En considérant un serveur nommé NBDserveur, un client nommé NBDclient et que le port TCP utilisé pour l'exportation est le port 1024, la commande à exécuter sur le serveur est :

        # dd if=/dev/zero of=/swap/swapfile bs=1k count=20480
	# nbd-server NBDclient 1024 /swap/swapfile
	# mkswap /swap/swapfile
      

Maintenant, le client doit utiliser la commande suivante :

        # swapon /dev/nd0
      

De nouveau, ce ne sont là que les principes généraux. Les noms de fichiers peuvent également être dépendants des noms ou adresses IP des stations.

Une autre solution de fichier d'échange est de créer un système de fichiers ext2 sur le NBD, d'y créer un simple fichier et, enfin, d'utiliser les commandes mkswap et swapon pour utiliser le fichier comme fichier d'échange. La seconde méthode est plus proche de celle du fichier d'échange sur NFS que la première.

A. Composants mémoire persistants

Cette section décrit brièvement les différents types de composants mémoire :

B. Déterminer la capacité et la vitesse d'une EPROM à destination d'un adaptateur réseau

Cette section provient de la version 5.0 de la documentation du projet etherboot. Elle expose les méthodes permettant de déterminer la capacité et la vitesse de l'EPROM à utiliser pour un type donné d'adaptateur réseau.

La capacité minimale d'une EPROM, acceptée par une carte réseau est de 8 Ko (2764). Des tailles de 16 Ko (27128) ou 32 Ko (27256) sont la norme. Quelques cartes supportent des capacités de 64 Ko (27512). On peut voir aussi des dénominations portant un C après le 27, comme 27C256 ; cela signifie que l'EPROM est de type CMOS. Equivalente à la version sans C, elle constitue un bon choix eu égard à sa faible consommation électrique. Vous utiliserez la plus petite taille d'EPROM possible afin de ne pas utiliser plus que de besoin l'espace mémoire supérieur, car des extensions du BIOS peuvent en avoir besoin De même, vous voudrez ne pas acheter une EPROM trop chère. Les EPROM de 32 Ko et de 64 Ko semblent être les moins coûteuses à l'unité. Les EPROM de moindre capacité semblent plus chères car elles ne sont pas produites sur la chaîne principale de fabrication.

Si vous ne pouvez trouver dans la documentation la capacité de l'EPROM supportée par votre carte, pour des adaptateurs sur slot ISA uniquement, vous pouvez la découvrir par essais-erreurs. Les adaptateurs sur slot PCI n'activent pas l'EPROM sauf indication contraire du BIOS. Prenez une ROM contenant quelques données (par exemple un générateur de caractères) et branché là dans son emplacement. Prenez garde de ne pas utiliser une extension BIOS pour ce test car elle pourrait être détectée et vous empêcher de démarrer votre machine. En utilisant le programme DOS debug, effacer divers régions de la mémoire. Supposons que que vous découvrez les données dans la fenêtre mémoire située des adresses CC00:0 à CC00:3FFF (= 4000 en hexadécimal = 16384 en décimal). Cela indique qu'une EPROM de 16 Ko est nécessaire. Si vous découvrez qu'une région mémoire est dupliquée, mettons la région CC00:0 à CC00:1FFF identique à CC00:2000-CC0:3FFF, cela signifie que vous avez introduit une EPROM de 8 Ko dans un emplacement prévu pour une EPROM de 16 Ko, et qu'il vous faut essayer une EPROM de plus grande capacité.

Notez que parce que les EPROM à 28 broches bénéficient de la compatibilité ascendante, il est possible que vous utilisiez une EPROM de plus grande capacité dans une branchement prévu pour une plus petite. .

Si votre ROM est d'une capacité supérieure à la taille de l'image, par exemple, une ROM de 32 Ko contenant une image de 16 Ko, vous pouvez stocker l'image dans n'importe quelle moitié de la ROM. Vous pourrez lire des conseils stipulant de placer deux copies de l'image sur la ROM. Cela fonctionne mais n'est pas recommandé car la ROM risque d'être activée deux fois ou ne fonctionnera pas du tout si c'est une PCI/PnP. Cela est toléré par Etherboot car le code vérifie s'il a déjà été activé, et la seconde activation avorte. La méthode recommandée est de combler la seconde moitiée avec des données inertes. Remplir avec des 1 est recommandé car il s'agit là de l'état naturel de l'EPROM et nécessite moins de travail au programmateur de PROM. La commande Unix suivante engendre 16384 octets à la valeur 0xFF et les combine avec le contenu d'une ROM de 16 Ko pour créer une image de 32 Ko à l'usage du programmateur d'EPROM.

      # (perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage
    

La vitesse d'EPROM nécessaire dépend de la façon dont elle est connectée au bus de l'ordinateur. Si l'EPROM est directement connectée sur le bus, cas de beaucoup de composants de type NE2000, il vous faudra probablement vous procurer une EPROM dont la vitesse est au moins égale à celle de la ROM du BIOS principal. Typiquement 120-150 ns. Certaines cartes réseau jouent les médiateurs vers l'EPROM, introduisant des états d'attente qui peuvent permettre l'utilisation d'une EPROM plus lente. La lenteur de l'EPROM n'a pas beaucoup d'incidence sur la vitesse d'exécution d'Etherboot car celui se duplique en mémoire avant de s'exécuter. Il parait que Netboot fait de même.

Si vous disposez de votre propre équipement de programmation d'EPROM, il existe une jolie collection d'utilitaires de conversion de formats de fichiers d'EPROM à http://www.canb.auug.org.au/~millerp/srecord.html. Les fichiers produits par le procédé de construction d'Etherboot sont entièrement en binaire. Un convertisseur simple de format, du binaire vers le format hexadécimal Intel, est disponible sur le site web d'Etherboot à http://etherboot.sourceforge.net/bin2intelhex.c. Vous pouvez aussi utiliser l'utilitaire objcopy, inclus dans le paquetage binutils :

      # objcopy --input-target binary --output-target ihex binary.file intelhex.file
      # objcopy --input-target ihex --output-target binary intelhex.file binary.file
    

Etherboot est considéré comme capable de créer des ROM compatibles avec les caractéristiques PnP des adaptateurs réseau sur slot PCI. Une erreur résiduelle dans les entêtes a été éliminée. Cependant, certains BIOS ne prennent pas en compte cette modification, aussi ai-je écris le script Perl swapdevids.pl pour effectuer la rotation des entêtes en cas de besoin. Vous devrez expérimenter les deux méthodes et déterminer laquelle fonctionne. Ou vous pouvez récupérer le contenu d'une ROM qui fonctionne (RPL, ou ROM PXE) en utilisant le script Perl disrom.pl. Les champs à examiner sont ceux concernant le type du périphérique (base, inférieur, interface). Cela doit être 02 00 00 mais certains BIOS demandent 00 00 02 à cause d'une ambiguité dans les spécifications originelles.

C. Fournisseurs de stations sans disques

Le guide pratique original "Machines sans disque" mentionne les noms des fournisseurs suivants :