[gPXE-devel] [PATCH][lkrn] add cmdline and ramdisk support

Miller, Shao Shao.Miller at yrdsb.edu.on.ca
Tue Jun 1 11:39:51 EDT 2010


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


More information about the gPXE-devel mailing list