[Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

maxire · Le 04/06/2015, à 16:05

Bonjour,

J'ai mis en place un serveur LTSP - Debian Jessie qui fonctionne parfaitement.

Celui-ci envoie un noyau 64 bits aux machines clientes indépendamment de l'architecture de ces machines.

J'aimerais envoyer un noyau 32 bits ou 64 bits en fonction de l'architecture de la machine cliente.

Mais voilà, si je lis la description de l'option DHCP 93 dans RFC 4578 supposée donner l'architecture du client pxe, je ne vois pas de distinction possible entre les deux architectures.
Je peux distinguer x86-64 eft ,ia32 efi mais du x86 64 bits et x86 32 bits je ne vois pas.

Le document que j'ai mis en lien date de 2006, peut-être n'est-il pas à jour?

Je précise que j'utilise dnsmasq comme serveur dhcp/tftp.

Une solution simple serait de n'envoyer que des noyaux 32 bits, mais par curiosité intellectuelle j'aimerais tout de même savoir si ce que je demande est possible.

Dernière modification par maxire (Le 06/06/2015, à 19:11)

J5012 · Le 04/06/2015, à 22:00

a la fin de ce doc : https://help.ubuntu.com/community/Ubunt … sArchSetup
il y a une explication : le script utilise une sous-routine substrings pour distinguer l'archi powerpc

j'ignore si il s'agit de l'adresse mac ?

Zakhar · Le 04/06/2015, à 23:24

A l'époque où j'avais monté un PXE avec tout le tintouin (DHCP server, TFTP, NFS, etc...) j'avais constaté que les "clients" demandaient plusieurs images, jusqu'à tomber sur un truc qui existait, mais je ne me souviens pas de l'ordre exact.

Si tu as encore des machines uniquement 32 bits (c'est rare, même le PC de ma mère qui était déjà un bas de gamme il y a 7 ans supporte le 64 !), le mieux est de tester.

Tu devrais pouvoir constater, soit avec un coup de Wireshark ou un coup de strace (sur le TFTP) sur le serveur de fichiers ce qu'il se passe et les différences entre les différents PC qui démarrent.

Ca m'étonnerait bien qu'il n'y ait pas une différence visible.

Après, selon que tu maîtrises ou pas le parc de machines qui se connecte, tu peux toujours flagger les "quelques" (en supposant qu'il y a peu d'ordinosaures) 32 bits avec leur adresse Mac, parce que pour sûr, à un moment donné le PC demande un fichier contenant sa propre adresse Mac, ce qui permet de mettre une image par PC si on veut aller jusque là.

Dernière modification par Zakhar (Le 04/06/2015, à 23:25)

droopy191 · Le 05/06/2015, à 11:23

Salut,

Voyez aussi comment fait debian pour les cd multiarch, qui permettent depuis un meme cdrom de démarrer sur les 2 architectures.

maxire · Le 06/06/2015, à 11:31

Merci pour les réponses,

@j5012, ok mais ceci n'est valable que pour distinguer le cas particulier du powerpc en utilisant l'option DHCP 60 détaillée ici

option vendor-class-identifier "AAPLBSDPC"

Cela me semble un petit peu complexe à gérer.

@Zakhar, exact, il existe la solution de filtrer les adresses mac des quelques machines 32 bits, mais même dans ce cas, outre le fait que je n'ai aucune envie de gérer ce filtre, cela ne fonctionnera pas, j'explique pourquoi plus bas.

@droopy191, c'est une solution que j'utilise déjà pour distinguer un système 32 bits d'un 64 bits afin d'utiliser par exemple la bonne version de clonezilla.

Il suffit de mettre dans le menu de démarrage réseau dans pxelinux.cfg quelque chose comme ceci:

label Clonezilla-live
MENU LABEL Clonezilla Live (Ramdisk)
COM32 ifcpu64.c32
APPEND have64 -- nohave64

LABEL have64
MENU HIDE
KERNEL clonezilla/vmlinuz
APPEND initrd=clonezilla/initrd.img boot=live config noswap nolocales edd=on nomodeset ocs_live_run="ocs-live-general" ocs_live_extra_param="" keyboard-layouts="fr" ocs_live_batch="no" locales="fr_FR.UTF-8" vga=788 nosplash noprompt fetch=tftp://192.168.1.9/clonezilla/filesystem.squashfs

LABEL nohave64
MENU HIDE
KERNEL clonezilla32/vmlinuz
APPEND initrd=clonezilla32/initrd.img boot=live config noswap nolocales edd=on nomodeset ocs_live_run="ocs-live-general" ocs_live_extra_param="" keyboard-layouts="fr" ocs_live_batch="no" locales="fr_FR.UTF-8" vga=788 nosplash noprompt fetch=tftp://192.168.1.9/clonezilla32/filesystem.squashfs

Les répertoires clonezilla et clonezilla32 hébergent respectivement les version 64 bits et 32 bits de Clonezilla.

Cette solution est tout à fait utilisable dans le cadre d'un serveur LTSP.

Finalement, quel est le problème?
Je peux bien indirectement distinguer une architecture 32 bits d'une 64 bits en utilisant syslinux/pxelinux, donc charger initialement les noyaux et images initiales compatibles le problème vient de la deuxième étape de lancement celle du script init fourni par un serveur nfs ou nbd.

Je suis bloqué par le fait que c'est le serveur DHCP qui va fournir le chemin vers la racine en utilisant l'option DHCP 17.
Avec dnsmasq cette directive est la suivante:

# The rootpath option is used by both NFS and NBD.
dhcp-option=17,/opt/ltsp/amd64

Je n'ai aucune possibilité, ou je n'ai pas trouvé le moyen, d'envoyer le chemin de la racine /opt/ltsp/i386 dans le cas d'un client avec une architecture 32 bits.

La solution que j'envisage est de modifier la génération de l'image initiale du client de manière à utiliser un chemin de racine nfs fixe plutôt que dynamique.

Je vous tiens au courant de la suite, j'ai encore quelques doutes sur la manière de procéder, il faudra peut-être également modifier un ou plusieurs scripts des images initiales.

Dernière modification par maxire (Le 06/06/2015, à 11:33)

Zakhar · Le 06/06/2015, à 14:35

Ah ben là t'es allé beaucoup plus loin que moi !

J'avais juste fait ça par curiosité sur 1 seul PC, pour explorer la possibilité.

S'il n'y a pas moyen via le DHCP de faire l'aiguillage, à la phase où tu en es, ne peux-tu pas faire l'aiguillage sur l'image elle-même en chargeant un init spécifique ?
C'est peut-être hors de proportion ce que je dis, parce que ça veut peut-être dire patcher le kernel ou des éléments de ce niveau là du boot.

maxire · Le 06/06/2015, à 15:43

EN fait c'et beaucoup, plus simple que je ne pensais, il suffisait de modifier la configuration de dnsmasq en mettant en commentaire la directive:

# The rootpath option is used by both NFS and NBD.
#dhcp-option=17,/opt/ltsp/amd64

et en utilisant le menu démarrage intégré à dnsmasq comme ceci:

# We don't want a PXE menu since we're using a graphical PXELinux menu.
pxe-prompt="Press F8 for boot menu", 3

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
pxe-service=X86PC, "Boot from network amd64", /ltsp/amd64/pxelinux
pxe-service=X86PC, "Boot from network i386", /ltsp/i386/pxelinux

J'ai alors ceci au démarrage du client:

Il suffit de choisir de démarrer un client 32 bits ou 64 bits.
Ce n'est pas tout à fait automatique mais cela fonctionne, je ne sais pas pourquoi, pour le savoir il va falloir que je mette sérieusement le nez dans initrd.img.

MicP · Le 06/06/2015, à 16:58

Je ne sais pas si, comme pour GRUB2, la commande cpuid est accessible depuis un menu PXE, mais je viens de trouver dans ce lien ce qui suit :

…Is it possible for grub2 to detect whether the processor is x64 or i386…
…I'm aware of the grub2 CLI command cpuid -l, to check for long mode, but I'm not sure if or how that can be used in menu.cfg. …

ANSWER : Remove only the menu entries (leaving all the config stuff at the top) and put them into two different files, one for 64-bit and one for 32-bit. Then, add code like below into the main menu.cfg to load the appropriate menu file for the system.
if cpuid -l; then
    configfile /boot/grub/grub-amd64.cfg
else
    configfile /boot/grub/grub-i386.cfg
fi

maxire · Le 06/06/2015, à 18:38

@MicP, c'est une idée équivalente à ce que je décris dans le message #5, il est effectivement possible d'utiliser grub en boot PXE à la place de syslinux/pxelinux, si tu veux essayer, le processus est décrit en boot pxe avec grub, je me souviens l'avoir testé pour un boot pxe d'une machine X64 EFI.

Utiliser Grub m'éloignerait trop du boot pxe standard de Debian LTSP.
En plus je commence à dominer syslinux/pxelinux, je n'ai pas envie de me disperser.

Dernière modification par maxire (Le 06/06/2015, à 18:41)

maxire · Le 06/06/2015, à 19:10

Je mets le fil en résolu, en fait je ne pourrais réaliser une connexion en automatique qu'en installant tous les modules de syslinux (par exemple linux.c32) dans les conteneurs (en tout cas au moins un) des clients, le petit menu proposé au démarrage avec un choix par défaut d'une architecture amd64 me va très bien.

Merci pour les suggestions.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 04/06/2015, à 16:05

[Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#2 Le 04/06/2015, à 22:00

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#3 Le 04/06/2015, à 23:24

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#4 Le 05/06/2015, à 11:23

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#5 Le 06/06/2015, à 11:31

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#6 Le 06/06/2015, à 14:35

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#7 Le 06/06/2015, à 15:43

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#8 Le 06/06/2015, à 16:58

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#9 Le 06/06/2015, à 18:38

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

#10 Le 06/06/2015, à 19:10

Re : [Résolu]Boot PXE - Distinction entre Architecture X86-64 et i386

Pied de page des forums