[syslinux] fixing debian's hd-media image

[Ady Ady]

> it works. (boots into the d-i installer, I don't care if the installer
> is missing stuff, booting it is all we care about here.
 
 
OK, so let's add complexity (but not the whole thing, not yet).

We already have:

target
├── EFI
│   ├── BOOT
│   │   ├── BOOTX64.EFI
│   │   ├── LDLINUX.E64
│   │   └── SYSLINUX.CFG
│   └── syslinux
├── initrd.gz
└── linux

The 'EFI/BOOT/syslinux/' directory was a leftover from your prior tests 
(and not a requirement in my prior email). In the previous (our 
"effective first") test, it was not used. Since we are going to use it 
now, and in order to be coherent with other directory and file names 
related to Syslinux in FAT(32) (and considering we are troubleshooting 
a "generic" procedure), we are going to rename 'EFI/BOOT/syslinux/' to 
'EFI/BOOT/SYSLINUX/' (all uppercase).

* Once we don't have 'EFI/BOOT/syslinux/' anymore (because we renamed 
it to all-uppercase), in your "target" device, we want (at least) one 
additional directory:
 _ "target/EFI/BOOT/SYSLINUX/EFI64/"

(all uppercase)

* From the 'efi64' subdirectory (tree) for syslinux files in your 
OS/package/archive, you want to copy all "*.c32" files to:
 
 _ "target/EFI/BOOT/SYSLINUX/EFI64/*.c32"

Let me re-emphasize this point: the "*.c32" modules we are copying 
right now are from the "efi64" subdirectory (and down its tree). If you 
put in this (newly-created) "target/EFI/BOOT/SYSLINUX/EFI64/" directory 
any c32 module that is not from the efi64 platform, eventually 
something will fail and we will have no way to know what's wrong. 
Please, do _not_ mix in this directory any c32 file from a different 
platform (not from "efi32", and not from "bios").

The reason we are copying _all_ the c32 modules from efi64 at this step 
is for simplicity when troubleshooting. We probably don't really need 
all of them, but such potential "clean-up" can be done later-on, when 
we know that all the basic things are working as expected.


Now we want to test whether the basic functionality of vesamenu.c32 in 
efi64 works with this setup, _without_ focusing on the specific linux 
kernel you eventually would like to boot nor on the whole Debian menu; 
in these next steps (and in the next test), we are focusing on 
vesamenu.c32 and our current directory tree.

* You need to create a new file:

_ "target/EFI/BOOT/SYSLX64.CFG"

Please note: "SYSLX64.CFG" is supported since Syslinux 6.04-pre1. Older 
versions do not support this configuration file name.

Please note: There are several ways to achieve the main goal; this is 
only one of them. I'm trying to make it as simple as possible for 
troubleshooting (IMHO).


The (initial, for now) content of "target/EFI/BOOT/SYSLX64.CFG":

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

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 ###

* Save / close any relevant opened files and unmount the image (or the 
fs of your testing device).

When booting in UEFI x64 mode in your next test, you should see a boot 
menu. 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.

Regards,
Ady.