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

Todd Stansell todd at stansell.org
Sat Mar 19 03:34:39 UTC 2016

On Fri, Mar 18, 2016 at 11:05:25AM +0000, Michael Brown wrote:
> 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.

Correct.  Since doing this is not a multiboot standard, the pxegrub code also
makes sure the MBI_FLAG_DRIVES flag is unset.  Solaris also requires the
MBI_FLAG_BOOTDEV flag is set with mbinfo.boot_device = 0x20ffffff.

> 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.

Our patch was simply using a BOOTPLAYER_t structure, so we don't seem to need
a full-sized DHCP packet.  All of the complex solaris options are passed as
kernel arguments.  So, going with the simple solution is probably fine.

> >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.

Solaris uses gzip to compress their images, so it would need to support that.

> 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.

It would be great if it automatically decompressed it like other bootloaders,
but I suppose I'm okay with any solution that works. :)


More information about the ipxe-devel mailing list