[syslinux] efi config hang
ady-sf at hotmail.com
Tue Dec 11 09:37:12 PST 2018
> 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
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
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)
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
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:
(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),
might consider this to be a bug (and it probably is).
More information about the Syslinux