[ipxe-devel] Windows having problems parsing iBFT from recent iPXE versions?
Floris Bos
bos at je-eigen-domein.nl
Wed Oct 29 17:14:46 UTC 2014
On 10/29/2014 04:53 PM, Michael Brown wrote:
> On 29/10/14 15:01, Floris Bos wrote:
>>> Have you tried performing a bisection (http://ipxe.org/howto/bisect)
>>> to identify the commit causing the problem?
>>
>> Problems seem to start after this commit:
>>
>> [tcp] Do not send RST for unrecognised connections
>
> That commit doesn't touch the iBFT in any way, suggesting that the
> underlying problem is a build artefact rather than a code change.
>
I'm not sure if it is actually the iBFT that is the problem.
My initial guess was that was the case because the nameserver does not
show up in "ipconfig", and my iSCSI disk is not there.
But perhaps Windows does not copy the nameserver from iBFT, but normally
gets that by using normal DHCP later on.
And the real problem is that network connectivity is just screwed up,
perhaps caused by iPXE leaving the network adapter in some kind of state
Windows is not expecting.
That I am seeing DHCP requests, and repeated ARP requests for the IP of
my SAN after Windows booted supports the theory that it does have the
iBFT, but that Windows is able to transmit network packets, but somehow
has problems receiving them.
- Several commits I tried before "[tcp] Do not send RST for unrecognised
connections" all work properly
- Several commits I tried after, all fail
- It might be coincidence, but I just managed to get HEAD to work by
reversing both "[tcp] Do not send RST for unrecognised connections" and
"[tcp] Defer sending ACKs until all received packets have been
processed" both which do hackery in src/net/tcp.c.
> A problem is that the SAN-booted OS is likely to clear the screen
> almost immediately, meaning that the warning message would not be seen
> in practice.
But if I am doing a SAN installation couldn't the warning be printed the
moment I do the sanhook command?
Would still be some time before it has finished downloading boot.wim and
clears the screen.
> You can get some diagnostic information from the information printed
> by pxeprefix.S when undionly.[k]kpxe starts up. In particular, the
> "XXXkB free base memory after PXE unload" will show you how much
> memory was free before iPXE claimed its base memory segments.
"577kB free base memory after PXE unload" with Virtualbox.
Yours sincerely,
Floris Bos
More information about the ipxe-devel
mailing list