[Dnsmasq-discuss] using gPXE in chainloader mode

[rance at frontiernet.net]

Quoting Simon Kelley <simon at thekelleys.org.uk>:

> rance at frontiernet.net wrote:
>> First my reference url is http://www.etherboot.org/wiki/pxechaining
>>
>> Seems the guys at etherboot have created gPXE, Im sure that this is old
>> news to many of you on this list, but it was news to me.
>>
>> Im using dnsmasq and its built in tftp server and everything Ive tried
>> to do with dnsmasq has worked first time.  (Read: Great Job Simon!)
>>
>> Now I have a question about how to integrate gPXE into my dnsmasq setup.
>>
>> <quoting reference url>
>> When the chainloaded gPXE starts up, it will issue a fresh DHCP request
>> and boot whatever the DHCP server hands out. The DHCP server is
>> currently set up to hand out the gPXE image, which means that you will
>> be stuck in an infinite loop: PXE will load gPXE which will load gPXE
>> which will load gPXE which will load gPXE...
>>
>> The easiest way to break this cycle is to configure the DHCP server to
>> hand out gPXE only for the first DHCP request. Using ISC DHCPD, you can
>> edit /etc/dhcpd.conf to contain:
>>
>>   option space gpxe;
>>   option gpxe-encap-opts code 175 = encapsulate gpxe;
>>   option gpxe.bus-id code 177 = string;
>>
>>   if not exists gpxe.bus-id {
>>       filename "undionly.kpxe";
>>   }
>>
>> <end quote>
>>
>> I can't find any documentation as to if this is possible with dnsmasq, I
>> searched the list archives for pxe boot problems but I didnt find
>> anything related to my question.
>>
>> I don't recall seeing any logic around the decision of WHICH filename
>> option to send to pxebooted clients.
>>
>> Any Ideas?
>>
>
> You can control which filename is sent using tags.
>
> dhcp-boot=net:<tag>,<filename>
>
> but that knowledge only transforms the problem into getting a tag set
> for the initial PXE, but not the gPXE request, or vice-versa.
>
> The procedure suggested for dhcpd isn't possible for dnsmasq; you can't
> set a tag based on the presence or otherwise of an arbitrary option in
> the DHCP request.
>
> You can match in the contents of the vendorclass option, using
> --dhcp-vendorclass. That might work, but a quick check of the code seems
> to show gPXE sending a very familiar string as its vendorclass, so it
> may well be impossible to tell the two requests apart that way.
>
> The best we to check is to use wireshark to grab the DHCP requests, and
> look for the contents of the vendorclass option in each one (option
> number 60). If they're different, devise a match string for
> --dhcp-vendorclass which matches one and not the other. If that's not
> possible, come back here and I'll look at adding the required facility.
>
>
> On a related note: people doing PXE should look at the dhcp-option-force
> directive, that's needed to get options to whatever a PXE server chain
> loads. The PXE code doesn't know what options the chain loaded code may
> want, so it  can't request them. Using dhcp-option-force you can send
> those options anyway. This is essential to get options to PXELinux, for
> instance.
>
>
> Cheers,
>
> Simon.
>
>
>

This message is to summarize for the list the results of my testing

configuration details:

netboot server os centos 5.1
dnsmasq version 2.40 installed as a package from the prmforge collection

gPXE compiled from source using fresh source sync using "git" on 12/21/07

ive set this up two different ways

I have made no changed to the dnsmasq setup at this point, I want to  
see where my current status is.

First, as I have an extensive pxeboot menu setup including opitons for  
netbooting the installers of several linux distros  i adding to the  
menu and fed a kernel command to the pxeclient.menu option and pxe  
downloads gpxe and boots that. gpxe does optain a fresh dhcp address  
but seems to ignore the boot instructions.

Looks like they have setup gpxe to parse the dchp response (which  
includes the filename) and selectively not boot it, line perhaps if  
the bootfile in the request is selectively ignored.

Ok, so I made a change to dnsmsq.conf to change the boot file name  
that is being used.