Perhaps a better way to interpret a gPXE .lkrn command-line passed by a previous boot-loader might be:
Parse filename=XXX and root-path=XXX options. This removes the assumption (of my patch) that the gPXE script feature is available and also removes the assumption that gPXE CLI commands are available at all. Unfortunately, it does not address the case where you wish to boot a kernel and initrd. However, additionally processing module=XXX (or image=XXX) might be a way to deal with that, since the gPXE 'initrd' command is really just an alias for 'imgfetch'. Related to the last paragraph would be the idea of allowing gPXE encapsulated options to include additional modules/images. Then a DHCP server can pass a kernel in the filename option and an initrd in such an encapsulated option. If we implement that, then the "module=XXX" processing just mentioned becomes a simple tie to a DHCP option, just as "filename=XXX" and "root-path=XXX" processing would be. There was a little bit of recent discussion[1][2] surrounding the occasional need to do more of what gPXE allows from the [smallish] space that conventional PXE environments provide. In that thread, I suggested[3] a protocol that could build gPXE scripts on-the-fly from a URI. Such a protocol could be tied to the incorporation of the gPXE scripting feature during build. I'd really enjoy reading what the gPXE core developer usual suspects have to offer. :) - Shao Miller [1] http://etherboot.org/pipermail/gpxe/2010-May/001039.html [2] http://etherboot.org/pipermail/gpxe-devel/2010-May/000197.html [3] http://etherboot.org/pipermail/gpxe-devel/2010-May/000203.htm _______________________________________________ gPXE-devel mailing list [email protected] http://etherboot.org/mailman/listinfo/gpxe-devel
