[gPXE] Chaining gPXE with intel PXE

Shao Miller Shao.Miller at yrdsb.edu.on.ca
Wed Apr 14 13:12:30 EDT 2010


Good day Shedis,

In regards to your NBP using HTTP instead of TFTP for downloading its files:

If the NBP implements TFTP itself and uses UNDI, you could add a huge 
hack to gPXE to interpret, intercept and translate TFTP packets built by 
the NBP into HTTP before putting them on the wire, and then to do the 
same thing in reverse.  What a crazy hack that would be.

If the NBP uses PXE's TFTP functions, you could add a hack to gPXE to 
actually perform the transfers via HTTP.  If gPXE was capable of 
listening on a port, you could even implement a TFTP service in gPXE 
(perhaps at 127.0.0.1:UDP:69) which could actually fetch its files over 
HTTP.  This would look pretty weird telling an NBP that their TFTP 
server is 127.0.0.1, but it would be an interesting hack.

Perhaps more reasonably, have you looked at Syslinux' 
syslinux/doc/sdi.txt?  Syslinux running atop gPXE can use HTTP, so 
syslinux/com32/modules/sdi.c32 could fetch via HTTP.

If you are simply booting an OS image into RAM (such as a .WIM), you 
could use MEMDISK (as Kyle and Joakim suggested), but this would mean 
the .WIM file would be in RAM twice: once within the MEMDISK image and 
once when loaded to RAM from the boot-loader on that MEMDISK image.

An alternative would be to boot from SAN, where the boot-loader on the 
SAN would load the .WIM into RAM.  Some SAN protocols you could consider 
are iSCSI and AoE...  I'd also written an HTTPDisk SAN protocol for gPXE 
which has not been merged into the main codebase.  This might or might 
not be interesting to you.

- Shao Miller


More information about the gPXE mailing list