[syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32

[Gene Cumm]

On Wed, Oct 7, 2015 at 6:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote:
>> -----Original Message-----
>> From: Gene Cumm [mailto:gene.cumm at gmail.com]
>> Sent: Wednesday, October 07, 2015 4:43 PM
>> To: For discussion of Syslinux and tftp-hpa; Geert Stappers
>> Subject: Re: [syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32
>>
>> On Wed, Oct 7, 2015 at 6:27 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
>>> On Wed, Oct 7, 2015 at 2:33 AM, Geert Stappers <stappers at stappers.nl> wrote:
>>>> On Tue, Oct 06, 2015 at 10:27:15PM -0400, Gene Cumm via Syslinux wrote:
>>>>> > On Fri, Oct 2, 2015 at 4:07 AM, Gene Cumm <gene.cumm at gmail.com> wrote:
>>>>> >>
>>>>> >> I have a patch that I think may help your situation of
>>>>> >> syslinux.efi being unable to load ldlinux.e64/ldlinux.e32 (though
>>>>> >> I don't know if any of you are using an EFI ia32 platform).
>>>>> >>
>>>>> >> The basics are that we try to enable UseDefaultAddress as it
>>>>> >> helps certain clients with routing and works on numerous other
>>>>> >> clients.  If we timeout on receiving a packet and have never
>>>>> >> received any packets, disable UseDefaultAddress and set the addresses manually.
>>>>> >>
>>>>> >>
>>>>> >> git://github.com/geneC/syslinux.git
>>>>> >> https://github.com/geneC/syslinux.git
>>>>> >>
>>>>> >> Branch 1efipxe
>>
>>
>> https://sites.google.com/site/genecsyslinux/sl604p0g18-x64.tgz?attredirects=0&d=1
>> https://sites.google.com/site/genecsyslinux/sl604p0g18-bios.tgz?attredirects=0&d=1
>>
>> Thanks Celelibi for finding that regression on DHCP options.  I never expected BOOTP field siaddr to be blank yet have a booting client.
>>
>>>>> On Fri, Oct 2, 2015 at 4:46 PM, Derrick M <derrick.martinez at gmail.com> wrote:
>>>>> > This works! Fixes my issue I have been having with the DL160s
>>>>>
>>>>> Further testing, preferably of the above binaries, on machines that
>>>>> previously had issues loading ldlinux.e64/ldlinux.e32 would be
>>>>> greatly appreciated as I know you've observed this issue and this
>>>>> seems like we might have a final resolution.
>>>>
>>>> Please tell in your feedback
>>>> if you did get a message about disabling UseDefaultAddress on the screen.
>>>
>>> And please try HTTP transfers too (especially DHCP option 210 set to
>>> an HTTP URL).  I have a feeling I need to implement some of the same
>>> logic into TCP too.  Reporting what you see on the screen will be
>>> helpful (ie "Failed to connect: %d" where %d is a number).
>>
>> Ashish Shivendra, these should be better binaries for larger testing.
>>
>> Thank you in advance.  Per-client quirks are some of the harder ones to test as often times contributors don't have machines affected by these quirks.
>
>
> On Wed, Oct 7, 2015 at 7:58 AM, Ashish, Shivendra
> <shivendra.ashish at hpe.com> wrote:
>> Still getting error
>>
>> Disable uderdefault address
>
> 1) I'm presuming this is actually "disable UseDefaultAddress"
>
>> Core_udp_sento: udp->configure unsuccessful
>>
>> This message lopping in console
>
> Not entirely surprising (for now) though I'd expect more output than
> just that and the rest of those messages would likely tell me exactly
> what the return codes are.
>
> More importantly, you didn't mention what else you observed or any
> details about your test.  I thought you just said the previous binary
> had initially good outlook on a DL380 G9?  Details like which machines
> work, which don't, and the basic layout of your PXE system would be
> helpful, including:
>
> - Make/model of system
> - UEFI firmware revision
> - What NIC type and port number?
> - UEFI extension agents (struggling to recall the proper term;
> comparable to a BIOS PXE OROM for add-in cards)
> - Was a proxyDHCP/PXE server involved in addition to DHCP?

> - TFTP or HTTP transfer
- TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server?

- Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server
live relative to the client and each other (ie different subnets)?

> - What precisely did you observe?  On the screen?  booting behavior?
> - Have you performed any packet captures, preferably an tap/packet
> mirror capture?

> In your case, the only obvious thing is that it seems like it's TFTP transfer.

-- 
-Gene