[gPXE] etherboot and WDS

[James]

On 15-Jan-10 15:22 Shao Miller wrote:
> Thanks for the detail, James.  If you are really stuck with Etherboot 
> (rather than gPXE) in your situation, a few more questions might help.
> 
> - What is on a client screen at the point where you deem the process to 
> have been a failure?

Me: 2.52.24.114, DHCP: 2.52.24.67, TFTP: 2.52.24.67, Gateway 2.52.24.65
Loading 2.52.24.67:boot\x86\wdsnbp.com ...(PXE).............done

Downloaded WDSNBP...

Architecture: x86
TFTP download failedProbing pci nic...
Probing isa nic...
Probing pci nic...
[rtl8139] - ioaddr 0xC100, irq 11, addr 00:21:D8:AB:A6:79 100Mbps half-duplex
Searching for server (DHCP).....
Me: 2.52.24.114, DHCP: 2.52.24.67, TFTP: 2.52.24.67, Gateway 2.52.24.65
Loading 2.52.24.67:boot\x86\wdsnbp.com ...(PXE).............done

Downloaded WDSNBP...

Architecture: x86
TFTP download failedProbing pci nic...
Probing isa nic...
<sleep>
FATAL: No bootable device.


> - If this is QEmu, are you aware that QEmu's built-in TFTP service is a 
> bit picky about paths?  Perhaps this does not apply to your situation, 
> but it's worth mentioning.

I am using an external tftp server.

> - Was your packet capture missing parts, such as the TFTP traffic?  Was 
> the capture taken from the RIS/WDS server?

yes.. I removed those.  Included everything else I thought was relevant.
Capture was taken from nic of qemu host.  qemu's virtual nic is bridged
to host nic.

> - You noted that Etherboot failed to offer an ARP response.  Do you 
> achieve different results when you statically map the MAC to the IP for 
> the client on the server?  You can use the 'arp -?' command in Windows 
> to read about using 'arp -s' to assign such a mapping.
> 
Did not try.

> It looks like in your Etherboot scenario, that the client is simply 
> trying all over again, hence the repeated file request.
> 
Right.  Etherboot is trying again because it didn't know how to download
the architecture specific file boot\x64\pxeboot.n12\000.

wdsnbp.com is "a boot program specifically designed to fix-up the DHCP info
in the BIOS as if the client directly contacted the PXE Server (as should be
the case, per the PXE spec)."

The above is from 
<http://social.technet.microsoft.com/Forums/en-US/itprovistadeployment/thread/ff41bfb9-799e-40ea-b5ef-4cdd319dba71>

So whatever this "fix-up" is didn't happen correctly.

James

> Best of luck,
> 
> - Shao Miller
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Attached Message Part
Type: image/jpeg
Size: 60661 bytes
Desc: not available
Url : http://etherboot.org/pipermail/gpxe/attachments/20100115/baad7340/attachment-0001.jpe