[syslinux] ALTERNATE TFTP SERVERS

[Jeffrey Hutzelman]

--On Tuesday, October 12, 2010 08:10:58 AM -0400 Gene Cumm 
<gene.cumm at gmail.com> wrote:

> On Tue, Oct 12, 2010 at 07:56, Gene Cumm <gene.cumm at gmail.com> wrote:
>> On Tue, Oct 12, 2010 at 04:45,  <Kjetil.Mikkelborg at kongsberg.com> wrote:
>>> I am also seeing this behavior;
>>>
>>> pxelinux 3.86 works nice with pxechain.o and sccm chainloaded, but
>>> replacing pxelinux.0 and pxechain.0 with 4.02 release, chainloading
>>> fails (or, actually it seems that it cannot pass ip::path right (::
>>> gets omittet or something))
>>>
>>> Anyone else seen this behavior?
>>>
>>> --Kjetil
>>
>> I just did some testing from the "boot: " prompt with 4.02.  For
>> reference, I used VMware Server 2.0.2 with a VM at VMHW-4 and another
>> at VMHW-7 (virtual hardware versions).
>>
>> "pxechain.com sl401/pxelinux.0" attempts to fetch
>> ::pxelinux.cfg/sl401/pxelinux.0 (for reference, version 4.01).
>>
>> "pxechain.com ::sl401/pxelinux.0" fetches the entire file and hangs
>> with on a single line of output: "TFTP boot: 172.16.23.1 pxelinux.0"
>> and does not respond to Ctrl-Alt-Del.
>>
>> "pxechain.com 172.16.23.130::pxelinux.0" (also 4.02) does the same
>> except of course from another server.
>>
>> "::sl401/pxelinux.0" loads PXELINUX 4.01 successfully but does not
>> reset anything else about the PXE environment (for example, current
>> working directory or current server).  "::sl403p4/pxelinux.0"
>> (4.03-pre4) and "172.16.23.130::pxelinux.0" do the same.
>>
>> From the VM at VMHW-4, I also tried PXELINUX 4.00 (loaded first to be
>> consistent) with the same results.
>
> Using 3.86, everything works.  Using PXELINUX-3.86 with pxechain.com
> from 4.02 also works while PXELINUX-4.02 with pxechain.com from 3.86
> does not (both as I expected).

Hrm.  It _might_ be interesting to rebuild pxechain with DEBUG defined. 
But probably not; by the time the "TFTP boot:" message gets printed, all 
that's left is to hand control to the PXE stack.

I have some code lying around to try doing the handoff via PXELINUX instead 
of directly to the PXE stack, which may be less sensitive to memory layout 
and more robust in the event of a failure.  I should really dig that up, 
test it, and send it along.

-- Jeff