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

[Gene Cumm]

> -----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?
- Where do the DHCP server and proxyDHCP/PXE 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?
- TFTP or HTTP transfer

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

-- 
-Gene