[syslinux] fixing debian's hd-media image

[Ady Ady]

> > When booting in UEFI x64 mode in your next test, you should see a boot
> > menu.
> 
> Nope:
> 
> *** Press enter to boot the default label ***
> Failed to load libcom32.c32
> Failed to load COM32 file SYSLINUX/EFI64/vesamenu.c32
> boot:
> 
> > I'd like to ask you to test all the entries in the menu and
> > report the results for each. If, instead, the boot menu does not show
> > up, we need to know the details / results too.
> >
> > A minor detail (that might be relevant for your report): we are
> > defining a TIMEOUT of 10.0 seconds. When you select "lslabel", the
> > result should show up on screen during those 10.0 seconds (unless you
> > press 'enter', or some other key, before that time), and then the boot
> > menu should show up again. The same goes for "pwdlabel". So, if you
> > want to take note of the results of each entry and you hadn't have
> > enough time, then, while in the boot prompt, simply press the "left
> > arrow" (or "cursor") key once and then the "right arrow" key once, or
> > change the TIMEOUT value, or select the same menu entry again from the
> > boot menu. IOW, the TIMEOUT value is relevant not only when the boot
> > menu is displayed on screen but also when the boot prompt is awaiting
> > some initial input.
> 
> I #disabled the timeout so that it wouldn't keep cluttering the screen
> when I was trying to take notes.
> 
> at the boot: prompt, hit tab, enter the 3 ...
> 
> boot:
> lslabel pwdlabel mylabel
> boot: lslabel
> [dir]           [dir] SYSLINUX        LDLINUX.E64
> [dir]  .             BOOTX64.EFI      SYSLX64.CFG
> boot: pwdlabel
> /EFI/BOOT/
> boot: mylabel
> (linux boots)
 
 
These are _not_ bad news.

The two c32 modules that don't need additional module libraries are 
working correctly (i.e. they execute with no errors, and the result is 
what we expected).

Since vesamenu.c32 requires additional c32 modules to work, there are 2 
methods to solve the problem.

For a customized, personal use, the solution is simple. But since the 
intention is to send a patch for Debian, we cannot take the "simple" 
solution.


Now, in spite of what you already attempted (that you wrote in another 
email) regarding the PATH directive, we are going to edit 
"target/EFI/BOOT/SYSLX64.CFG":

###  EFI/BOOT/SYSLX64.CFG  start ###

# Note that the path starts with NO slash
# and ends with a slash
PATH SYSLINUX/EFI64/

UI SYSLINUX/EFI64/vesamenu.c32
DEFAULT lslabel
PROMPT 1
# TIMEOUT 100
SAY *** Press enter to boot the default label ***

LABEL lslabel
COM32 SYSLINUX/EFI64/ls.c32

LABEL pwdlabel
COM32 SYSLINUX/EFI64/pwd.c32

LABEL mylabel
LINUX /linux
INITRD /initrd.gz

###  EFI/BOOT/SYSLX64.CFG  end ###


Since we are troubleshooting, we want to delete anything that could 
potentially cause some strange behavior (whether expected, or because 
of some (un)known bug). And so, I'll ask you to delete (at least for 
now):

_ target/EFI/BOOT/SYSLINUX.CFG

_ target/EFI/BOOT/SYSLINUX/EFI64/ldlinux.e64

Before performing the test (the same as I requested in my prior email), 
please double check that all the syslinux-related files are originated 
from the following binary packages:

_ syslinux-common_6.04~git20171011.af7e95c3+dfsg1-5

_ syslinux-efi_6.04~git20171011.af7e95c3+dfsg1-5


Since you have been mixing binaries from several different sources / 
builds / versions in your prior attempts / scripts, it is very 
important that you triple check that the binary files you are using now 
(in your "target" device/image) are exactly those I just posted. These 
packages are from current Debian "Testing" repo.


BEWARE:
 We are about to use the PATH directive. This PATH directive has 
several issues, inconveniences, shortcomings, and bugs. Hence, the next 
test _might_ "fail" to show the boot menu. According to (or depending 
on) your next report, we might need to perform some minor adjustments. 
IOW, if your next test fails, don't worry and report the results as 
accurately as possible.

Regards,
Ady.