[ipxe-devel] Two problems/bugs in iPXE related to multiple NICs

[Robin Smidsrød]

Hi Kevin,

We had a discussion on the IRC channel a little while back when someone
noticed that only the last entered sanboot/sanhook command would be in
the iBFT because the structure was reset each time one of these commands
were called. I seem to recall there was some discussion on how we could
list all hooked devices instead just one. No development has been done
on this, to my knowledge.

I'm surprised to hear that Windows doesn't want to initialize network
adapters not listed in the iBFT. What I've read (somewhere) is that
Windows will hold a static route to the iscsi target server on the NIC
it boots from that it will not allow removal of. Other network adapters
should operate as usual. Are you saying your observations contradict
this? If so, it'd be interesting to hear what Microsoft has to say on
the subject. Maybe try to post something in an MSDN forum to get their
feedback, or report a bug to them (using whatever is the proper method).

And yes, we don't have the habit of tagging stable releases, as all
releases on the master branch are considered stable. Development happens
on other clones. This apparently causes a lot of confusion for users.
Maybe it'd be wise to tag releases once every few months just to show
that there is forward motion in the project. What do you think, Michael?

-- Robin

On 13.02.2013 09:58, kevin at fantaplay.com wrote:
> Hi,
> 
> I'd like to share a couple bugs I've isolated related to iPXE in the
> hopes it will be useful in improving the program.  I'm not actually on
> the list so if you wish to reply please do so at krm at fantaplay dotcom.
> 
> The first issue relates to iSCSI boot and is current as of the Jan. 31,
> 2013 commit.  iPXE by design only writes a single NIC to the iBFT.
>  However, in systems with multiple NICs, Windows Server apparently will
> not activate NIC devices which are not listed in the iBFT.
>  Consequently, only one NIC can be used, which constitutes a crippling
> limitation in the typical server usage case.
> 
> In my own installation I worked around this by modifying iPXE source
> code to hardwire a second NIC entry, and this did work, but this is
> obviously a poor solution.  I've explained the issue in more detail here:
> 
> http://serverfault.com/a/478056/137215
> 
> The other bug I encountered is also related to the iBFT, but I am not
> sure it is current as at the time I was using a version of gPXE.  The
> issue related again to multiple NICs being in the system being booted.
>  Here's an excerpt of a post I made on serverfault.com
> <http://serverfault.com> explaining the issue:
> 
> ----
> Suspecting a problem in the information gPXE was placing in the iBFT, I
> programmed a boot sector which dumps the contents of the iBFT to the
> screen. Using this I found that the data written by gPXE is under
> certain circumstances erroneous.
> 
> As mentioned, gPXE only writes one NIC record into the iBFT, but in some
> situations, the information written to that one NIC record is jumbled
> up. The MAC address and PCI address will correspond to one NIC [the
> right one], but the local IP and gateway addresses will correspond to
> another [the wrong one]. This is most likely to happen if the SAN is not
> on the first NIC.
> 
> To add to the confusion, this incorrect iBFT information is written if
> gPXE boots automatically, but when booting from gPXE's command prompt,
> depending on the exact sequence of commands entered, the correct
> information may be written.
> ---- 
> 
> I suspect this problem may be related to what a comment in the iPXE code
> calls an "Ugly hack" in ibft.c, but I haven't confirmed this.
> 
> I hope this info will help improve your project.
> 
> Best regards,
> Kevin
>  
> 
> 
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>