[ipxe-devel] Incorrect next-server (QIP + Microsoft RIS/WDS)

[Michael Brown]

On Monday 19 Jul 2010 10:19:22 Tim Wright wrote:
> First-time poster so please be gentle!
> 
> We're seeing a few issues when attempting to PXE boot new HP systems with
> the QLogic NetXen onboard NICs (gPXE 0.9.9 embedded). I'm raising this
> directly with HP, but thought I'd post here too to see if anyone has any
> thoughts.
> 
> We use Lucent QIP (which I believe is just ISC DHCPd under the covers)
> *and* Microsoft RIS/WDS for our provisioning system for all x86 operating
> systems. QIP provides the IP lease, while RIS is configured to provide just
> the additional boot options. Systems which do not have a matching UUID in
> Active Directory will boot to the "OS Chooser" menu (startrom.com) by
> default.
> 
> My question is why is gPXE trying to load startrom.com (boot file name
> provided by proxydhcp), from the next-server provided by QIP (rather than
> proxydhcp/next-server)? I'm pulling my hair out here! I've read the Wiki
> article regarding MSRIS, but I don't seen to be even getting to that stage?

If you've raised the issue with HP then it's likely to bounce down to me 
eventually, since I'm the one who wrote the driver for NetXen.  :)

The problem in your case is that options from the DHCP server (QIP) are deemed 
to override options from the ProxyDHCP server.  This part is as per the PXE 
specification.  However the PXE spec also states that all options must come 
from a single source (i.e. we shouldn't be taking the next-server from one 
source and the filename from another).  This latter part is quite awkward to do 
within iPXE, which has many more potential sources of options (e.g. non-
volatile options stored on the NIC, options set via the command line) than are 
envisioned by the PXE spec.

Why is the QIP server providing a next-server address at all?  It sounds as 
though in your setup you are wanting the next-server and filename to be 
provided only by the RIS/WDS server.

The easiest fix (if you can do it) would be to stop the QIP server from handing 
out its apparently spurious next-server address.

(Redirected to the ipxe-devel list.)

Michael