[Dnsmasq-discuss] using gPXE in chainloader mode

rance at frontiernet.net rance at frontiernet.net
Sat Dec 22 01:49:10 GMT 2007


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.
>
>
>


I just got done testing gPXE with two different setups:

1) as a menu option in my already working pxe menu
2) as a dhcp-boot replacement for pxelinux.0

there is no package for gPXE you can ony "git" the source with the  
cvs/svn like "git" suite

as of todays sync download and compile, the referenced behavior did not occur.

im using dnsmasq 2.40 on centos 5.1 (via the rpmforge package set)

wireshark shows that the bootfile is sent correctly and gPXE is  
ignoring the bootfile when it should

I didnt spend too much time witg gPXE once I got it working the way I  
want to use it (as a boot menu option from my existing pxemenu)

I'm going to send a message to the etherboot discusstion list and see  
if I can confirm that its a fixed bug and not a fluke.

Rance






More information about the Dnsmasq-discuss mailing list