Quoting Simon Kelley <si...@thekelleys.org.uk>:
ra...@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.
