FWIW, I did have to patch gPXE to use a filename outside of the standard place for an environment that wouldn't accomodate conditionals. In my particular patch:<div><div>+#define DHCP_ROOT_PATH DHCP_ENCAP_OPT ( DHCP_EB_ENCAP, 17 )</div>
</div><div><div>+#define DHCP_BOOTFILE_NAME DHCP_ENCAP_OPT ( DHCP_EB_ENCAP, 67 )</div></div><div><div>+#define DHCP_ISCSI_INITIATOR_IQN DHCP_ENCAP_OPT ( DHCP_EB_ENCAP, 203 )</div></div><div><br></div><div>Were my choices (the third just because this environment also permitted me one option to encapsulate, so I put the gPXE iqn option under the encapsulated option as well. Figured adding stuff to the existing encapsulated option presented the least risk of conflict.</div>
<div><br></div><div><br><div class="gmail_quote">On Sat, May 22, 2010 at 8:55 PM, Miller, Shao <span dir="ltr"><<a href="mailto:Shao.Miller@yrdsb.edu.on.ca">Shao.Miller@yrdsb.edu.on.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have been watching Joshua Oreman's presentation at<br>
<a href="http://vimeo.com/11948216" target="_blank">http://vimeo.com/11948216</a> and was reminded of something...<br>
<br>
His use-cached setting helps a PXE -> gPXE to avoid a second DHCP<br>
transaction, by re-using the parameters obtained by the initial PXE. In<br>
this instance, the filename option will uselessly remain the name of the<br>
gPXE program itself. This is why any scenario making use of the<br>
use-cached setting will most likely have an embedded script (such as<br>
gpxelinux.0 does, with Syslinux). Thus use of use-cached seems to imply<br>
a one-to-one relationship between chained-to gPXE binaries and the files<br>
they will boot.<br>
<br>
So if you'd rather have a single instance of the gPXE program, maintain<br>
the ability to boot a DHCP-specified filename, and avoid a second DHCP<br>
transaction, some additional data (another filename) must be provided.<br>
Since this additional filename would be specific to gPXE, it might make<br>
sense to implement as a gPXE encapsulated option, and might provide a<br>
fine opportunity to allow for extended rules (such as allowing variable<br>
expansion) to apply.<br>
<br>
As another note, I don't think re-purposing DHCP option 209 would work,<br>
after all, since PXELINUX itself would attempt to fetch using the<br>
literal ${xxx} sequence inside any URIs, which would not work. Only if<br>
gPXE's file-fetching performed variable expansion might this work, but<br>
that seems like a lot of work to consider for which URIs expansion<br>
should be performed, etc.<br>
<font color="#888888"><br>
- Shao Miller<br>
_______________________________________________<br>
gPXE-devel mailing list<br>
<a href="mailto:gPXE-devel@etherboot.org">gPXE-devel@etherboot.org</a><br>
<a href="http://etherboot.org/mailman/listinfo/gpxe-devel" target="_blank">http://etherboot.org/mailman/listinfo/gpxe-devel</a><br>
</font></blockquote></div><br></div>