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

[Gene Cumm]

On Sun, Oct 11, 2015 at 8:03 PM, Ady via Syslinux <syslinux at zytor.com> wrote:
>
>> Let me know what kind of info would be useful for debugging the
>> mboot issue, and I will collect it all.  Also, EFI is still somewhat
>> new to me, so I don't know how to find the UEFI firmware revision
>> or UEFI extension agents.  I'll see if it's in the server manual,
>> but if you have an idea how one typically finds those, I'd appreciate
>> any pointers.
>>
>> Thanks again!
>>
>> --
>> Michael Glasgow <glasgow at beer.net>
>
> Any method useful for a "legacy" firmware (aka "BIOS"), should be
> available for UEFI.
>
> Some possible methods (please read all of them):
>
> _ Shown in a "normal" POST screen during boot, and usually shown also
> in the firmware setup screens. KISS :).

Always consider the extra boot option of the UEFI CLI, often an
unsupported boot option.

Remember, the uEFI firmware version is comparable to a BIOS-only
machine's BIOS version.

> _ Using some tool that retrieves DMI data; although such tool should
> rather have its database updated for new-ish hardware.
>
> _ hdt.c32. Erwan Velu has updated the hdt code recently, some of it for
> DMI. For these updates to be effective, it needs to be re-built from
> current git HEAD together with the core module, the library modules and
> the bootloader. Whether it would then work correctly (under UEFI), I do
> not know.
>
> _ Using the SYSAPPEND directive in the Syslinux configuration file
> (hint: then check the resulting generated Syslinux cookie for the
> relevant client system, or run 'cat /proc/cmdline' in the booted
> system). If the server boots with Syslinux, this method would apply to
> it too.
>
>
> A possible SYSAPPEND statement could be:
>
> SYSAPPEND 0x18000
>
> or its decimal alternative (in case the hex value fails for some
> reason):
>
> SYSAPPEND 98304
>
> should provide:
>
> BIOSVENDOR=     BIOS vendor name
> BIOSVERSION=    BIOS version
>
>
> Regards,
> Ady.
>
> PS: Could the issue with booting Xen be not related to mboot.c32, but
> rather to something else (for instance, to something like the current
> "keeppxe" failing)?

-- 
-Gene