[syslinux] efi config hang

[Ady Ady]

> What is F0?
 
 
See "prompt.cfg" in Debian's "hd-image"'s boot.img.


> or how do I test it?
 
 
That's an old directive that was "replaced" by the equivalent 'F10' 
directive (so you test it in the same exact way).

BTW, in other distribution media such as Debian's ISO images, it is 
already changed from "f0 f10.txt" to "f10 f10.txt". This should be sent 
to Debian as a patch (among others).


> > > _ the screen (under the default screen resolution of syslinux.efi +
> > > (vesa)menu.c32) is a mess and it cannot be completely clear / clean up;
> > > IOW, [CTRL]+[L] and 'MENU CLEAR' are partially (mostly) broken
> > >
> 
> I see that too.
> 
> which makes it hard to test as I often think the box has hung, but
> really it is just waiting for input at a prompt I can't see.
> and an option that displays text (both DISPLAY  and COM32 pwd.c32)
> don't do anything visible. so I can't tell if they ran or not.
 
 
You should be able to see the effects of the DISPLAY directive when 
testing the floppy image I sent you, because it starts with the boot 
prompt, not with a menu.

You could also see the result of pwd.c32 by executing it from CLI first 
(before going into the menu).

For testing purposes, and starting from the cfg file I sent you in the 
floppy image, you could also add between 20 and 28 "blank" lines (at 
least when using the default screen resolution) to the end of 
SYSLX64.CFG. Now imagine you have the screen full of garbage. When 
using this cfg file, press [ESC] twice, then '[CTRL]+[L]' and then 
("blindly") type in the command 'catl' (which is equivalent to 'cat.c32 
SYSLX64.CFG' in the cfg I sent you). The content of the cfg file should 
be displayed on screen, and since the last 20+ lines are now "blank", 
the effect should be and "almost-clean" screen with a boot prompt. The 
next command you type in should be shown more clearly now, and its 
result too.

This is of course just a workaround for this garbage screen; OTOH it 
makes the use of 'cat.c32 SYSLX64.CFG' more uncomfortable and less 
useful in its original purpose (which was to give some clue of the 
content of the cfg file while troubleshooting).

>From the above points regarding the garbage screen, an alternative 
would be to have a "blank.cfg":

SAY *** This file has 70 lines of blank lines.       ***
SAY *** The following lines are either               ***
SAY *** 70 [enter]s, or,                             ***
SAY *** 80 space characters per line x 70 [enter]s.) ***


instead of having them at the end of SYSLX64.CFG. Using 'cat.c32 
blank.cfg' should be a potential "dirty" workaround that might help 
during testing.

Of course, having this command as a menu entry in the boot menu during 
troubleshooting is also a possiblity.


> > > _ the DEFAULT directive is partially broken
> > >
> 
> What part is broken?
 
 
I'm not completely sure about the exact (incorrect) behavior. After 
executing vesamenu.c32 (not from the UI directive and not from the 
DEFAULT directive) and then [esc]aping the menu (so we are back in the 
boot prompt), by pressing [enter] in the boot prompt I would expect for 
the DEFAULT label to be executed, always; instead I am seeing that I am 
back into vesamenu.c32. This strange behavior requires further testing, 
using menu.c32 too, the CLI and several combinations of cfg files and 
labels with diverse sorting.

Considering the lack of development activity, I have no plans on 
testing this problem with the DEFAULT directive any time soon.


> > > both from CLI and from menu (no hang)
> 
> confirmed.
 
 
Which means that the problem you reported about "prompt.cfg" (which is 
supposed to trigger the help screens in Debian) is not that the help 
screens don't work. The feature (i.e. so-called message files, together 
with the DISPLAY and F1-12 directives) is basically working, but 
something else seems to be wrong when you choose the "help" entry in 
Debian's menu in UEFI mode.

This issue requires more testing in order to identify what exactly is 
wrong in Debian's boot menu. As I mentioned before, ATM I am not 
willing to do all the testing and reports for Debian, especially when 
there is no indication that either upstream nor downstream developers 
care (with very few exceptions, too-few).

BTW, Debian's prompt.cfg has one line INCLUDEing another cfg file, 
'exithelp.cfg'. Although I mentioned this "exithelp.cfg" file in my "15 
steps" in a previous email, I did not mention that this 'exithelp.cfg' 
file is incorrect, because I didn't want to add complexity to the 
instructions (and considering that your intention was/is to send a 
patch to Debian).

(This is not news to me; I've known about this incorrect cfg file for 
years, but Debian's bureaucracy and lack of useful reactions from my 
prior attempts to actually achieve some (additional) improvements took 
my patience over my limit.)


> may have found another debian patch bug:
> 
> ###################
> *** syslx64.cfg ***
> ###################
> 
> boot: hdtl
> Undef symbol FAIL: exp
> Failed to load libgpl.c32
> Failed to load COM32 file hdt.c32
> boot:
 
 
I'm not sure this is a problem with Debian's package; it is more 
probable that the problem is in upstream's HDT code. I do know that HDT 
has several "BIOSisms". If it is even possible to run hdt.c32 in UEFI 
mode at all, then perhaps some developer might be capable of solving 
this particular hang. Everyone is free to wish and hope.


> I was surprised that SYSLX64.CFG was found when it was in / and no cfg
> in EFI/BOOT
 
 
The _cfg_ file should be searched-for and found by syslinux.efi there; 
no surprise really. Perhaps re-reading the whole:

 www.syslinux.org/wiki/index.php/Install 

(and/or following some links within the wiki; hint: "see also")

might reduce some doubts (about that).

OTOH, if the c32 modules were left under /EFI/BOOT/, and no PATH 
directive was used, and all the c32 modules still worked as expected 
anyway, then this 
behavior is not documented. From the point of view of the developer(s), 
someone 
might consider this to be a bug (and it probably is).

Regards,
Ady.