[ipxe-devel] Solaris 10 x86 netbooting without using pxegrub

[Michael Brown]

On 17/03/16 23:11, Todd Stansell wrote:
> Well, it turns out that for the dhcpack bits, it's less complicated than we
> originally thought.  We turned to hacking on the ipxe code to try to see
> what's actually required to get this to work and now have a working patch.  It
> might not be ideal, but it does seem to work.  I'm including it as an
> attachment here.  We took the option of storing the dhcpack packet inside a
> setting and then also requiring another setting to actually use it.  That way
> an ipxe config could optionally have the multiboot code fire to embed the
> dhcpack only when it knows it's a solaris network boot that's required.
>
> Is there any chance some form of this patch could be implemented in ipxe so we
> don't have to run custom ipxe code?

What are the requirements that Solaris has here?

It looks as though Solaris expects to see a DHCPACK packet pointed to by 
the mbinfo's {drives_addr,drives_len} fields.

If so, then strip out everything relating to the solaris_dhcp_cache 
blob, and use create_fakedhcpack() to construct the DHCPACK.  This will 
create a DHCPACK containing the settings as actually used by iPXE for 
the relevant network device.  This is what our PXE API uses to provide 
the DHCPACK for PXENV_GET_CACHED_INFO; see pxe_fake_cached_dhcpinfo() in 
arch/x86/interface/pxe/pxe_preboot.c.

One easy solution would be to simply call pxe_fake_cached_info() before 
starting a Multiboot image to construct the standard set of DHCP packets 
as used by the PXE API, and then to pass the address of the DHCPACK via 
mbinfo.  This would have a negligible code size impact, which is good.

The downside is that the buffers used for the PXE API are exactly the 
size of a BOOTPLAYER_t structure (as defined by the PXE spec), and this 
buffer may not be large enough to hold a DHCP packet containing large 
number of options.  (See the comment in pxe_preboot.c for details.)

If we care about being able to pass a full-sized DHCP packet to Solaris, 
then it might be better to use create_fakedhcpack() directly.  This 
could potentially share the same buffer space in .bss16 as the three 
BOOTPLAYER_t packets used by pxe_preboot.c, since booting a Multiboot 
kernel is mutually exclusive with booting a PXE NBP.

> We're also still working on the idea of uncompressing the image on the fly so
> we don't have such a huge image to transfer over the network, but this is a
> good first step.  Any thoughts on this topic would be greatly appreciated.

We already have support for the raw decompression algorithm in 
crypto/deflate.c, which we use for PNG image support.  We don't 
currently have support for the gzip headers/footers.

There are (at least) two ways that this could usefully be implemented. 
One would be to add support for a compressed HTTP content/transfer 
encoding.  The HTTP core does now provide an infrastructure to allow 
this sort of feature to be plugged in as a link-time option.

Other options would be to perform the decompression on demand (e.g. via 
a "gunzip" command), or to automatically perform decompression for 
Multiboot images since that's the way that some other bootloaders 
already behave.

Michael