[ipxe-devel] Windows having problems parsing iBFT from recent iPXE versions?

[Steve Cross]

Floris,

I'm a little late reading this email, but you say that you are having
issues with Windows iSCSI on the Intel NUC series. I am curious which exact
NUC model you are using. I ask because I have three here at my house all
running completely diskless iSCSI and have been for nearly two years
without issue. Perhaps I could provide some assistance. I apologize if you
already provided this information, I managed to lose all emails prior to
this one.

Steve

*Steve Cross*
hairlesshobo at stevecross.org

On Thu, Oct 30, 2014 at 11:31 AM, Floris Bos <bos at je-eigen-domein.nl> wrote:

> On 10/30/2014 02:02 PM, Michael Brown wrote:
>
>>
>>  - iPXE communcation seems to end with an iSCSI read response, iPXE ACKs
>>> nicely
>>> - then there is this long wait on Windows startup (waiting for disks?),
>>> and during that there are some TCP retransmissions of an iSCSI NOP
>>> command trying to keep the connection warm from SAN to virtualbox.
>>> - straight after that Windows takes over, there is some DHCP/ARP traffic
>>> (not shown below), a LLMNR request for wpad, and a new iSCSI login.
>>>
>>> <snip>
>>>
>>> - Seems the iSCSI read response is retransmitted lacking the last ACK.
>>> Those packets may arrive when Windows is about to take over.
>>> - Windows does not seem to do any iSCSI communication
>>>
>>
>> Fantastic debugging work.  Could you possibly copies post the two
>> captures (either as attached raw .pcap files, or uploaded to
>> https://appliance.cloudshark.org/upload/ ?
>>
>>
> https://www.cloudshark.org/captures/a781ff622adc
> https://www.cloudshark.org/captures/0968b06118f5
>
>
> Note that some communication is missing.
> E.g. traffic between the virtualbox VM where Windows is being installed
> (192.168.178.4), and the virtualbox VM that plays for DHCP/installation
> server (192.168.178.100), doesn't touch the host system and therefore isn't
> in this capture.
>
>
>  The iBFT is not created until you attempt to boot from the SAN target.
>>>>
>>>
>> My mistake; the iBFT is actually created at the moment of the "sanhook"
>> command, which would give time for any warning message to be displayed.
>> The architectural issue is then that iPXE has no mechanism in place for
>> displaying non-fatal error messages.  We could make int13_describe() return
>> an error, but this would then prevent the SAN device from being hooked.  We
>> could hack a printf() into int13.c, but that kind of crossover between
>> mechanism and policy is the kind of ugliness that I've worked hard for over
>> a decade to eliminate from this codebase.
>>
>> Since it's a fairly pathological system in which the memory above 512kB
>> is all used by the time iPXE starts up, and since it's definitely not the
>> cause of the problem you're experiencing, I don't propose to do anything
>> about it now.
>>
>
> Did had that issue on other systems, and still think not getting any
> warning and it mysterically failing is very annoying.
> Affects the Intel NUC series, and doubt I'm the only one that tried to use
> those in diskless setups.
>
>
> Yours sincerely,
>
> Floris Bos
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20141030/75ae3c88/attachment.htm>