[gPXE-devel] environment variable expansion in 'filename'?

Jarrod Johnson jarrod.b.johnson at gmail.com
Sun May 23 09:45:11 EDT 2010


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:
+#define DHCP_ROOT_PATH DHCP_ENCAP_OPT ( DHCP_EB_ENCAP, 17 )
+#define DHCP_BOOTFILE_NAME DHCP_ENCAP_OPT ( DHCP_EB_ENCAP, 67 )
+#define DHCP_ISCSI_INITIATOR_IQN DHCP_ENCAP_OPT ( DHCP_EB_ENCAP, 203 )

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.


On Sat, May 22, 2010 at 8:55 PM, Miller, Shao
<Shao.Miller at yrdsb.edu.on.ca>wrote:

> I have been watching Joshua Oreman's presentation at
> http://vimeo.com/11948216 and was reminded of something...
>
> His use-cached setting helps a PXE -> gPXE to avoid a second DHCP
> transaction, by re-using the parameters obtained by the initial PXE.  In
> this instance, the filename option will uselessly remain the name of the
> gPXE program itself.  This is why any scenario making use of the
> use-cached setting will most likely have an embedded script (such as
> gpxelinux.0 does, with Syslinux).  Thus use of use-cached seems to imply
> a one-to-one relationship between chained-to gPXE binaries and the files
> they will boot.
>
> So if you'd rather have a single instance of the gPXE program, maintain
> the ability to boot a DHCP-specified filename, and avoid a second DHCP
> transaction, some additional data (another filename) must be provided.
> Since this additional filename would be specific to gPXE, it might make
> sense to implement as a gPXE encapsulated option, and might provide a
> fine opportunity to allow for extended rules (such as allowing variable
> expansion) to apply.
>
> As another note, I don't think re-purposing DHCP option 209 would work,
> after all, since PXELINUX itself would attempt to fetch using the
> literal ${xxx} sequence inside any URIs, which would not work.  Only if
> gPXE's file-fetching performed variable expansion might this work, but
> that seems like a lot of work to consider for which URIs expansion
> should be performed, etc.
>
> - Shao Miller
> _______________________________________________
> gPXE-devel mailing list
> gPXE-devel at etherboot.org
> http://etherboot.org/mailman/listinfo/gpxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe-devel/attachments/20100523/6ca2987b/attachment.html 


More information about the gPXE-devel mailing list