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

Gene Cumm gene.cumm at gmail.com
Wed Oct 7 04:13:08 PDT 2015


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.

-- 
-Gene


More information about the Syslinux mailing list