[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