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 _______________________________________________ gPXE mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe
