1. Principe
L'installation se décompose en 3 étapes :
- amorcer un noyau Linux depuis le réseau ;
- amorcer un système minimal ;
- exécuter l'installeur proprement dit.
La première partie est générique, c'est-à-dire qu'elle est applicable à n'importe quelle distribution. Les deux autres, par contre, sont spécifiques à DrakX, l'installeur Mandriva. Et il n'existe malheureusement aucune documentation officielle publique, ce qui est assez handicapant pour une utilisation professionnelle... Il faut donc se contenter d'une ancienne version, disponible en ligne chez un particulier1, et aller à la pêche aux informations auprès des développeurs quand celle-ci se révèle insuffisante.
Chacune de ces étapes est décrite en détail successivement.
2. Boot réseau
Sur une machine vierge, il n'y aucun système d'exploitation installé. Le but poursuivi ici étant de procéder à distance, l'utilisation d'un média amovible est à proscrire. La solution consiste donc à utiliser PXE (Pre-boot eXecution Environment). Cette fonctionnalité permet de récupérer un exécutable sur un serveur du réseau local pour amorcer la machine que l'on veut installer. La taille de cet exécutable étant limité, il n'est pas possible de récupérer un noyau Linux directement, ce qui explique l'utilisation d'un bootstrap minimal qui va permettre de choisir entre plusieurs noyaux.
Le support de PXE est présent sur toutes les cartes réseau récentes. Néanmoins, ce support est parfois désactivé par défaut, et il faut alors passer par le BIOS pour l'activer. Attention, l'option correspondante n'est pas toujours explicitement nommée PXE, mais parfois « Rom Boot » ou « Rom Image ». Si ce support n'est pas présent, il reste possible d'utiliser une émulation logicielle avec EtherBoot2. Ceci nécessite néanmoins l'utilisation d'un média amovible, sur lequel il faut installer une image générée avec rom-o-matic.net3. À noter que QEmu, et donc Xen en mode virtualisation matérielle, supportent Etherboot nativement, et permettent donc également ce type d'installation.
2.1 Serveur DHCP
PXE est une technologie développée à l'origine par Intel, utilisant le protocole DHCP pour passer des informations supplémentaires au client. Il est donc nécessaire de disposer d'un serveur DHCP qui va répondre à ces requêtes spécifiques, en précisant l'adresse du serveur TFTP, ainsi que le nom de fichier à récupérer sur celui-ci (relativement à la racine du serveur). Voici deux exemples de configuration possibles.
group {
# serveur TFTP
next-server 192.168.0.1;
# fichier à récupérer
filename "/X86PC/linux/linux.0";
host foo {
hardware ethernet 00:16:3e:00:00:01;
fixed-address 192.168.100.1;
}
}
Ici, les machines identifiées par leur adresse MAC comme appartenant au groupe ainsi créé recevront systématiquement une réponse PXE à toutes leurs requêtes DHCP.
class "PXE" {
# identification des requêtes PXE
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
# serveur TFTP
next-server 192.168.0.1;
# fichier à récupérer
filename "/X86PC/linux/linux.0";
}
class "Etherboot" {
# identification des requêtes Etherboot
match if substring (option vendor-class-identifier, 0, 9) = "Etherboot";
# serveur TFTP
next-server 192.168.0.1;
# fichier à récupérer
filename "/X86PC/linux/linux.0";
}
Ici, seules les requêtes de type PXE ou Etherboot, quelle que soit leur machine d'origine, recevront une réponse PXE. À noter que pour Etherboot, l'utilisation de l'option PXE_DHCP_STRICT lors de la génération de l'image permet d'éviter l'utilisation d'une classe spécifique.
2.2 Serveur TFTP
Il faut ensuite configurer un serveur TFTP. Celui disponible dans la distribution se configure comme un service xinetd. Le seul paramètre important est le répertoire de départ (option -s), qui sert à effectuer un changement de racine au démarrage :
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s /var/lib/tftpboot
cps = 100 2
flags = IPv4
log_on_failure += HOST USERID ATTEMPT
}
2.3 PXELinux
Enfin, il faut installer et configurer un bootstrap. Dans notre cas, c'est PXELinux4, une variante de SYSLinux, maintenue par H. Peter Anvin (dont une interview est parue dans un ancien numéro de ce magazine). L'installation est triviale. Il suffit de mettre l'image exécutable sous la racine du serveur TFTP, de façon à être récupérable par le client, en utilisant le nom fourni par la réponse DHCP. Le paquetage pxelinux le fait automatiquement.
La configuration est un peu plus complexe. Il faut d'abord choisir le fichier de configuration utilisé. En effet, une fois récupéré et exécuté par le client, pxelinux recherche successivement plusieurs fichiers de configuration potentiels, et s'arrête au premier trouvé. Pour ce faire, il effectue des requêtes TFTP vers son serveur d'origine, en cherchant dans un répertoire pxelinux.cfg un fichier nommé d'après son UUID, son adresse MAC, puis plusieurs variations sur son adresse IP, avant de se rabattre sur un fichier nommé default. Ceci permet de facilement mettre en place des configurations spécifiques à une ou plusieurs machines. Voici pour commencer un fichier de configuration générique, que l'on sauvegardera donc comme pxelinux.cfg/default :
DISPLAY boot.txt
PROMPT 1
TIMEOUT 500
DEFAULT local
LABEL local
LOCALBOOT 0
LABEL memtest
kernel images/memtest/memtest.bin
LABEL mdv2008.1-i86
kernel images/mdv/2008.1/i86/vmlinuz
append initrd=images/mdv/2008.1/i86/all.rdz ramdisk_size=128000 root=/dev/ram3 vga=788
LABEL mdv2008.1-x64
kernel images/mdv/2008.1/x64/vmlinuz
append initrd=images/mdv/2008.1/x64/all.rdz ramdisk_size=128000 root=/dev/ram3 vga=788
Cette configuration définit 4 images bootables, les deux premières correspondant respectivement à un boot local et à un test mémoire utilisant memtest. Les deux suivantes sont les cibles d'installation proprement dites, correspondant à une Mandriva 2008.1 en 32 et 64 bits. Les options présentes en début de fichier correspondent à un fichier texte affiché par le client, servant de catalogue des images disponibles, et à un délai maximum de 50 secondes avant de reprendre l'image par défaut, le boot local. Il s'agit donc d'une configuration très conservatrice : même en déclenchant par erreur un boot réseau au démarrage (touche [F12] pour une machine Dell, par exemple), il n'y a aucun risque de déclencher accidentellement une procédure d'installation potentiellement destructrice.
Les kernels et initrd spécifiés dans cette configuration proviennent du répertoire isolinux/alt0 (ou isolinux/alt1 pour une version légèrement différente) dans l'arborescence de la distribution. Ils doivent être présents sur le serveur TFTP, pour des raisons évidentes, et leur chemin relatif au fichier exécutable de pxelinux. Une astuce, si le miroir utilisé est situé sur la même machine que le serveur TFTP, consiste à remonter son arborescence de fichier dans celle de ce dernier avec l'option bind :
mount /var/lib/ftp/pub/mandriva/official \
/var/lib/tftpboot/X86PC/linux -o bind
3. Première partie de l'installeur
En utilisant la configuration présentée jusqu'ici, un client effectuant un boot PXE se retrouve dans un écran l'invitant à faire un choix entre quatre possibilités. Sélectionner l'une des cibles d'installation provoque le chargement d'un noyau et d'un système minimal, correspondant à la première partie de l'installeur Mandriva (stage 1 pour les intimes).
Cette étape correspond en fait à la partie de l'installeur Mandriva spécifique à une méthode d'installation donnée (réseau, disque dur, CD). C'est cette étape que l'on trouve également sous la forme d'images à graver sur un média d'installation dans le répertoire install/images. Elle est complètement transparente dans le cas d'un support autonome, comme un CD, mais elle est interactive dans le cas d'une installation réseau. Il faut donc automatiser cette étape également. Ceci se fait en passant un certain nombre de paramètres à l'installeur, agrégés ensemble au sein d'un unique paramètre passé au kernel chargé par pxelinux : automatic=param1:valeur1,param2=valeur2,.... Dans la suite de cet article, il est donc question de paramètre et de sous-paramètre pour faire la distinction entre les deux.
3.1 Configuration réseau
La configuration réseau proprement dite consiste à sélectionner une interface, puis soit à préciser une configuration IP statique complète, soit à sélectionner l'auto-configuration par DHCP.
Un exemple de configuration statique ressemble à interface:eth0,network:static,ip:192.168.0.100,netmask:255.255.255.0,gateway:192.168.0.1,dns:192.168.0.1. Dans ce cas, une fois l'installation terminée, la machine cible sera correctement configurée avec les mêmes paramètres réseau. Mais, il faut par contre mettre en place autant de cibles différentes dans la configuration de pxelinux que de machines à installer. Plutôt qu'énumérer ces différentes possibilités dans le fichier de configuration par défaut, il est plus simple alors de profiter du mécanisme de sélection du fichier de configuration, puisque l'adresse de la machine visée est connue. L'utilitaire Gethostip (provenant du paquetage syslinux) permet d'obtenir la forme hexadécimale de l'adresse 192.168.0.100, déterminant ainsi qu'il faut utiliser le fichier pxelinux.cfg/C0A80064 :
DEFAULT mdv2008.1-x64
LABEL mdv2008.1-x64
kernel images/mdv/2008.1/x64/vmlinuz
append initrd=images/mdv/2008.1/x64/all.rdz ramdisk_size=128000 root=/dev/ram3 vga=788 automatic=interface:eth0,network:static,ip:192.168.0.100,netmask:255.255.255.0,gateway:192.168.0.1,dns:192.168.0.1
Même en automatisant la création de ces fichiers par des scripts, cette méthode reste fastidieuse. Une configuration dynamique unique est plus simple à gérer, d'autant plus que la mise en place initiale requiert de toute façon un serveur DHCP. Dans ce cas, le paramètre devient plus simplement interface:eth0,network:dynamic. Deux problèmes se posent néanmoins.
D'abord, la machine cible sera installée avec une configuration IP dynamique, ce qui n'est pas toujours souhaitable. Même si le serveur DHCP assigne toujours la même adresse à cette machine, il reste un problème de dépendance lors du boot. Une procédure de post-installation est alors nécessaire pour modifier cette configuration.
Ensuite, il n'y a aucune garantie que la première interface réseau pour le noyau Linux (eth0) corresponde à la première interface réseau pour le BIOS de la machine. Autrement dit, quand la machine possède plusieurs interfaces, celle qui fait la requête PXE initiale n'est pas forcément celle qui fait la requête DHCP lors de cette première étape. Une configuration DHCP trop restrictive, n'autorisant les réponses qu'à des adresses MAC précises, risque fort d'être bloquante ici en ne répondant qu'à la requête initiale, et en ignorant la seconde. Débrancher la seconde interface ne semble pas suffisant pour régler le problème, même en utilisant la valeur wired plutôt qu'une interface précise pour le sous-paramètre interface, manifestement à cause de bugs dans la détection de l'interface active 5. Bref, la solution la plus efficace consiste à désactiver toutes les interfaces réseau, sauf une.
3.2 Choix du miroir
Après la configuration réseau proprement dite, il faut récupérer la seconde partie de l'installeur. Le sous-paramètre method indique comment, et une série de sous-paramètres spécifiques à la méthode choisie indique où. Typiquement, l'ensemble ressemble à method:http,server:mirror.domain.com,directory:/pub/mandriva/official/2008.1/x86_64. Parmi les autres méthodes réseau, on dispose également de NFS et de FTP.
3.3 Limitation du nombre de caractères
Une limitation de pxelinux fait que les options passées au kernel, c'est-à-dire le contenu de la directive append, ne doit pas dépasser 256 caractères. Plus exactement, tout caractère au-delà de cette limite sera simplement et silencieusement ignoré, ce qui est toujours amusant à diagnostiquer. Or, cette limite est relativement facile à atteindre, surtout avec une configuration statique, ou des noms de fichiers relativement longs. Pour contourner ce problème, il y a deux solutions.
D'abord, tous les sous-paramètres possèdent une forme abrégée. Un exemple complet peut ainsi s'écrire automatic=int:eth0,netw:static,ip:192.168.0.100,netm:255.255.255.0,gat:192.168.0.1,dns:192.168.0.1,met:http,ser:mirror.domain.com,dir:/pub/mandriva/official/2008.1/x86_64.
Ensuite, lorsqu'on maîtrise le miroir utilisé, il est tout à fait possible de mettre en place des liens symboliques permettant d'abréger les références aux fichiers. Par exemple, un simple lien /mdv2008.1-x64 vers /pub/mandriva/official/2008.1/x86_64 permet de passer de 36 à 16 caractères.
4. Seconde partie de l'installeur
À l'issue de la précédente étape, l'installeur passe à la seconde partie (stage2 pour les intimes), c'est à dire l'interface graphique GTK bien connue. Celle-ci commence par l'acceptation de la licence, puis un enchaînement d'étapes conduisant à la mise en place de la distribution sur la machine cible. Ce sont ces étapes qu'il faut automatiser.
Le paramétrage devenant plus complexe, il devient nécessaire de passer par une fichier de configuration, qui doit se trouver sur le miroir utilisé. Ce qui implique de maîtriser le miroir en question, alors que pour les étapes précédentes ce n'était pas nécessaire. À moins bien sûr de convaincre l'admin du miroir distrib-coffee.ipsl.jussieu.fr de mettre en place un fichier spécialement pour vous, mais ça risque d'être cher à négocier :-). Le nom de ce fichier doit être passé en utilisant le paramètre kickstart, ou sa version courte ks. Un exemple complet de configuration pxelinux incluant l'ensemble de ces paramètres ressemble donc à ceci :
LABEL mdv2008.1-x64
kernel images/mdv/2008.1/x64/vmlinuz
append initrd=images/mdv/2008.1/x64/all.rdz ramdisk_size=128000 root=/dev/ram3 vga=788 automatic=int:eth0,net:dhcp,met:http,ser:mirror.domain.com,dir:/mdv2008.1-x64 ks=/auto_inst.cfg
4.1 Fichier de configuration
DrakX est un programme écrit en Perl. Le fichier de configuration automatique est en fait un fragment de code Perl, qui va être évalué à la volée, et surchargeant la valeur de certaines variables. Ce qui implique notamment qu'il doit être syntaxiquement correct, ce qu'il est facile de vérifier&:
[guillaume@oberkampf articles]$ perl -c auto.cfg
auto.cfg syntax OK
De façon plus précise, il s'agit de définir une variable $o comme une référence de table de hachage, dont les clés correspondent aux différentes étapes de l'installation, et dont les valeurs sont les paramètres de ces étapes. Un exemple valant mieux qu'un long discours :
$o = {
'superuser' => {
'password' => 's3cr3t',
},
'locale' => {
'lang' => 'fr',
'country' => 'FR',
},
'net' => {
'ifcfg' => {
'eth0' => {
'isUp' => 1,
'DEVICE' => 'eth0',
'BOOTPROTO' => 'dhcp',
'NEEDHOSTNAME' => 'yes',
'ONBOOT' => 'yes',
}
}
},
'timezone' => {
'ntp' => 'pool.ntp.org',
'timezone' => 'Europe/Paris',
'UTC' => 1
},
'default_packages' => [
'urpmi',
],
'security' => 2,
'autoExitInstall' => 1,
};
Cet exemple montre une installation ultra-minimaliste, avec uniquement l'utilisateur root, une configuration DHCP, et urpmi prêt à fonctionner.
Une première remarque concerne la sécurité. Dans l'exemple donné ici, le mot de passe de l'utilisateur figure ici en clair. Il est également possible d'utiliser la forme chiffrée, telle qu'elle figurera dans le fichier /etc/shadow, mais cela reste une très mauvaise idée si le miroir sur lequel figure ce fichier est accessible. Mieux vaut soit passer par une étape interactive pour cette étape, soit mettre en place une procédure de post-installation automatique, comme montrée plus loin, ou manuelle. Dans ce dernier cas, il importe évidemment de procéder à celle-ci immédiatement après l'installation.
Une deuxième remarque concerne la généricité. Par exemple, comme il est possible de préciser la liste des paquetages à installer, il est tentant d'énumérer par le menu tous les paquetages voulus. Cependant, on se heurte très vite à un problème de flexibilité, si le même fichier est amené à être utilisé pour installer des machines différentes. Par exemple, des machines 32 et 64 bits, avec des paquetages dont le nom diffère entre les deux architectures. En principe, seules les paquetages de bibliothèques, que l'on installe rarement explicitement, présentent cette particularité, mais il existe quelques exceptions, typiquement OpenOffice, dont la version 64 bits figure dans le paquetage openoffice.org64, pour des raisons historiques. Comme précédemment pour la configuration IP de la première partie, il est bien sûr possible de maintenir plusieurs fichiers de configuration dédiés, et donc plusieurs configurations pxelinux pour pointer vers l'un ou l'autre en fonction de la machine à installer, mais c'est très vite fastidieux. Ou encore, de garder un seul fichier de configuration Drakx, et de tirer profil du fait qu'il s'agisse de code Perl pour exécuter du code arbitraire, sur ce modèle :
'default_packages' => [
(`arch` eq 'x86_64' ? 'openoffice.org64' : 'openoffice.org' )
],
Mais ce système présente vite des limites. Lorsqu'on est confronté à ce type de problème, il vaut mieux abandonner l'idée de le résoudre lors de l'installation, et le résoudre après, à l'aide d'outils dédiés à la gestion de configuration d'un parc de machine, comme Cfengine 6.
Une autre façon de résoudre ce problème de généricité est de repasser en mode interactif sélectivement pour certaines étapes. C'est d'ailleurs la seule façon pour tout ce qui est bloquant pour l'installation, comme le partitionnement. Et c'est également une bonne idée pour cette étape, potentiellement destructrice : imaginez la machine d'un utilisateur qui boote malencontreusement par PXE parce qu'un livre posé sur le clavier active la touche F12 au démarrage... La clé suivante rend le partitionnement et le formatage interactif :
'interactiveSteps' => [
'doPartitionDisks',
'formatPartitions'
],
Il existe bien évidemment de nombreux autres paramètres possibles, il faut consulter la documentation pour les détails. Malheureusement, autant la première partie de l'installeur n'a guère évoluée, autant cette deuxième partie s'est enrichie, notamment au rythme des avancées technologiques matérielles et logicielles, et l'obsolescence des informations disponibles se fait souvent sentir.
4.2 Post-installation
DrakX permet d'exécuter du code arbitraire à la fin de l'installation, dans l'environnement de l'installeur d'abord, dans l'environnement restreint du système installé ensuite. Il est possible de cette manière de mettre en place une procédure de post-installation automatisée plus ou moins complexe.
Pour être plus concret, ce code correspond à un ensemble de commandes qui sont exécutées par un shell. L'exécution étant totalement masquée, il est conseillé de rediriger la sortie de ce script dans un fichier qui sera consultable après l'installation, en prenant garde au chemin utilisé :
'postInstallNonRooted' => '(
) >/mnt/root/drakx/postInstallNonRooted.log 2>&1',
'postInstall' => '(
) >/root/drakx/postInstall.log 2>&1',
Ce premier exemple montre comment mettre en place un véritable mot de passe aléatoire pour l'utilisateur root, mettre en place une clé publique ssh pour celui-ci, et s'assurer que sshd est configuré pour autoriser cet utilisateur à se loguer.
'postInstall' => '
# installation clé publique
mkdir /root/.ssh
cat > /root/.ssh/authorized_keys <<EOF
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAuaB3SySQ4xaxvM8EFHRFwhGHY1S60QGezxK7CNqgZGzyrBfshoyKzqMeUqRl98chT0tlykMcYxuLJ4RwRIFtxyj2JIgwbrU1r71ZRSk66GOuuUUCHyRQ9X8Nh/x9W6t/XwYPrbXXJqP2C91qDFq1OC8DnzWyr6vwS8KuoQNP6e0= rousse@stalingrad
EOF
# configuration sshd
perl -pi -e "s/^PermitRootLogin.*/PermitRootLogin without-password/" /etc/ssh/sshd_config
chkconfig --add sshd
# mot de passe aléatoire
perl -e "print map { chr(int(rand(94)) + 32) } 0..8" | passwd --stdin
) >/root/drakx/postInstall.log 2>&1'
Ce deuxième exemple montre comment configurer urpmi manuellement, pour éviter les noms de médias par défaut, très pénibles à utiliser en ligne de commande à cause de la présence d'espaces dans leur nom. Et au passage, on évite d'utiliser d'autres médias que main durant l'installation pour gagner du temps, puisqu'ils sont de toute façon enlevés à la fin.
'media' => [
{
type => 'media_cfg',
url => 'drakx://media',
selected_names => 'Main'
},
],
'postInstall' => '(
# désinstallation des médias
urpmi.removemedia -a
# installation manuelle
urpmi.addmedia --mirrorlist '$MIRRORLIST' main.release media/main/release
urpmi.addmedia --mirrorlist '$MIRRORLIST' main.updates media/main/updates
urpmi.addmedia --mirrorlist '$MIRRORLIST'contrib.release media/contrib/release
urpmi.addmedia --mirrorlist '$MIRRORLIST'contrib.updates media/contrib/updates
) >/root/drakx/postInstall.log 2>&1'
Ce troisième exemple montre comment mettre en place une configuration IP statique, même après avoir utilisé DHCP lors de l'installation. Au passage, on note que l'on ne peut pas récupérer le nom de l'hôte par la commande hostname, car le client DHCP ne configure malheureusement pas celui-ci7. Il faut donc la récupérer depuis le DNS (qui doit donc être correctement configuré).
'postInstall' => '(
# récupération des paramètres
ip=`/sbin/ifconfig eth0 | awk \'/inet/ {print $2}\' | awk -F: \'{print $2}\'`
nm=`/sbin/ifconfig eth0 | awk \'/inet/ {print $4}\' | awk -F: \'{print $2}\'`
gw=`ip route list 0.0.0.0/0 | awk \'{print $3}\'`
dns1=`awk \'/^nameserver/ {print $2}\' /etc/resolv.conf | head -n 1`
dns2=`awk \'/^nameserver/ {print $2}\' /etc/resolv.conf | tail -n 1`
fqdn=`host $ip | awk \'/domain name pointer/ {print $5}\' | sed -e \'s/\.$//\'`
host=${fqdn%%.*}
domain=${fqdn#*.}
# mise en place des fichiers
cat > /etc/hosts <<EOF
127.0.0.1 localhost
$ip $fqdn $host
EOF
cat > /etc/sysconfig/network <<EOF
NETWORKING=yes
HOSTNAME=$fqdn
GATEWAY=$gw
EOF
cat > /etc/sysconfig/networking-scripts/ifcfg-eth0 <<EOF
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=static
ADDRESS=$ip
NETMASK=$nm
DOMAIN=$domain
DNS1=$dns1
DNS2=$dns2
EOF
) >/root/drakx/postInstall.log 2>&1'
Et ce quatrième exemple montre l'initialisation de Cfengine, après avoir récupéré un fichier update.conf depuis le miroir, et en définissant une classe dédiée à la mise en place initiale des clés.
'postInstall' => '(
# mise en place manuelle du nom de l'hôte
ip=`/sbin/ifconfig eth0 | awk \'/inet/ {print $2}\' | awk -F: \'{print $2}\'`
host=`host $ip | awk \'/domain name pointer/ {print $5}\' | sed -e \'s/\.$//\'`
hostname $host
# synchronisation forcée de l'horloge
ntpdate ntp.domain.com
# bootstrap cfengine
wget http://mirror.domain.com/pub/update.conf -O /etc/cfengine/update.conf
export CFINPUTS=/etc/cfengine
cfagent -q -v --define bootstrap
) >/root/drakx/postInstall.log 2>&1'
5. Conclusion
L'installation automatisée nécessite la mise en place d'une infrastructure non négligeable : serveur DHCP, serveur TFTP, et éventuellement un miroir local. Cependant, il y a de fortes chances que les deux premiers soient déjà en place dans n'importe quelle organisation de taille raisonnable, et le dernier possède un intérêt même en dehors de ce besoin particulier. L'investissement est donc généralement principalement une question de temps, mais celui-ci en vaut largement la peine dès lors qu'il est souvent nécessaire d'installer ou de réinstaller des machines. Et l'automatisation présente une solution largement plus souple, notamment grâce aux possibilités de post-installation, que les solutions de type clonage. Reste donc le problème du manque de documentation... J'espère que cet article aura contribué à diminuer cet obstacle.
Un grand merci à Erwan Velu et à Pixel, pour leur relecture attentive et leurs commentaires.
Liens
- http://members.shaw.ca/mandrake
- http://etherboot.org/wiki/index.php
- http://syslinux.zytor.com/pxe.php
- http://qa.mandriva.com/show_bug.cgi?id=31479
- http://qa.mandriva.com/show_bug.cgi?id=32725
