[syslinux] efi config hang
ady-sf at hotmail.com
Fri Dec 7 05:41:27 PST 2018
> On Thu, Dec 6, 2018 at 10:00 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:
> > First, I'm confused. In the prior "whole" setup (the one you generated
> > after my 15 steps, plus one workaround), was/is the basic boot menu at
> > least "working" when you used the workaround for the buggy PATH
> > directive when booting in UEFI mode? I mean:
> > "PATH EFI/BOOT/SYSLINUX/EFI64/"
> > in
> > "target/EFI/BOOT/SYSLX64.CFG".
> > It is not perfect, but at least it should show the boot menu in UEFI
> > mode, and not hang immediately.
> > Could you please confirm?
> It did show the boot menu,
> I can use the arrow keys to navigate the menu,
> I can select the installer and it runs
> If I select "Help" and enter, or tab and enter, it hangs.
> help, tab, enter hang:
> And.. in trying to verify syslinx version, I have found another hang:
> efi boot, see menu, hit ^c, hung.
> legacy boot, ^c gets me a boot: prompt.
If you want to test whether the "help" files work, you select the
relevant row and press enter. I don't know why you would press tab, ^c
and then enter for this.
I am very much aware of the shortcomings of syslinux.efi. If you expect
syslinux.efi to behave exactly as the BIOS variant, you are going to
get disappointed, as I am.
It's been several years since I last tested syslinux.efi with DISPLAY
files (as those that should show the "help" for Debian's boot menu), so
I don't accurately remember the problems I found back then (but I do
remember that there are problems).
> > Regarding the "prompt.cfg" you are now trying to investigate (which is
> > not the one in boot.img), the following is (potentially) the first in a
> > series of simple, iterative, progressive tests and feedback. And no,
> > I'm not going to just write the ending/working result, in particular
> > when I don't know/understand the new goal.
> prompt.cfg is the Help option from the debian installer boot.img.
Yes, that's the one from boot.img. But the cfg you posted is:
menu label ^Help
and you said that prompt.cfg does not exist (in that particular
run/test). That cfg has at least 2 problems by itself (even before I
start any kind of test), and that's the cfg you reported as failing
when you started this new email thread, which is not the one from
> > If we don't know what is wrong/failing, then we need "basic" step by
> > step testing (iterations) for troubleshooting.
> > Using 6.04~git20171011.af7e95c3+dfsg1-6 packages from Debian Unstable
> > for all syslinux-related files.
> > target
> > └── EFI
> > └── BOOT
> > ├── BOOTX64.EFI
> > ├── LDLINUX.E64
> > ├── libcom32.c32
> > ├── libutil.c32
> > ├── vesamenu.c32
> > ├── pwd.c32
> > ├── ls.c32
> > ├── cat.c32
> > └── SYSLX64.CFG
> └── EFI
> └── BOOT
> ├── BOOTX64.EFI
> ├── cat.c32
> ├── LDLINUX.E64
> ├── libcom32.c32
> ├── libutil.c32
> ├── ls.c32
> ├── pwd.c32
> ├── SYSLX64.CFG
> └── vesamenu.c32
> > All in the same dir, we don't change WD, we don't mix it with BIOS, we
> > don't need the crappy PATH directive.
> > ### EFI/BOOT/SYSLX64.CFG start ###
> > # Note that there is no "splash.png" background
> > # This is a command
> > UI vesamenu.c32
> > # The DEFAULT should rather be a label, not a command
> > DEFAULT vesamenulabel
> > # If we have an active ("uncommented") UI directive,
> > # then the PROMPT directive makes no diff.
> > # This command is here anyway, in purpose.
> > PROMPT 1
> > # Let's try to clear the screen when we load the menu
> > MENU CLEAR
> > LABEL vesamenulabel
> > COM32 vesamenu.c32
> > LABEL pwdlabel
> > COM32 pwd.c32
> > LABEL lslabel
> > COM32 ls.c32
> [dir] . LDLINUX.E64 libcom32.c32 menu.c32
> boot: BOOTX64.EFI cat.c32 ls.c32l.c32 pwd.c32
> > LABEL catlabel
> > COM32 cat.c32
> > APPEND /EFI/BOOT/SYSLX64.CFG
> (dumps this file to the screen)
> > # To be tested from the boot prompt, using a different label
> > LABEL vesamenulabel2
> > COM32 vesamenu.c32
> > APPEND SYSLX64.CFG
> screen clears
> system seems to hang.
> I see no cursor, enter, ^v, nothing seems responsive.
I still don't get what that '^c' has to do with selecting the "Help"
menu entry. I'm not denying the possibility that BIOS and UEFI variants
of vesamenu could react differently to '^C'. What I'm saying is that if
the basic functionality is not working (i.e. select, then press enter,
show the help files), then why try to "catch" it in some misbehavior?
Since ^C is supposed to "interrupt boot in progress" (whatever that
means), apparently vesamenu.c32 in UEFI simply seems to hang? Maybe.
With the screen resolution issues under UEFI in general, and with the
"clear screen" being so poorly managed (or rather plainly mismanaged)
by syslinux.efi + vesamenu.c32, I wouldn't even care to test the "^C"
> > ### EFI/BOOT/SYSLX64.CFG end ###
> > The result might not be a nice, readable screen, but it should not hang
> > nor give errors about vesamenu.c32.
> > Could you please confirm this (too)?
> > Could you also please try the "equivalent" (not exactly the same, but
> > similar) to the above simple UEFI-only setup in a separate BIOS-only
> > case? I hope by now you can see which small details are relevant in
> > order to "translate" from one platform to the other.
> copied the files from bios into $target/boot/syslinux/
> copied/renamed the .cfg file (no changes needed)
> cp \
> /usr/lib/syslinux/modules/bios/vesamenu.c32 \
> /usr/lib/syslinux/modules/bios/libcom32.c32 \
> /usr/lib/syslinux/modules/bios/libutil.c32 \
> /usr/lib/syslinux/modules/bios/ls.c32 \
> /usr/lib/syslinux/modules/bios/cat.c32 \
> /usr/lib/syslinux/modules/bios/pwd.c32 \
> cp $target/EFI/BOOT/SYSLX64.CFG $target/boot/syslinux/syslinux.cfg
> sudo extlinux --install $target/boot/syslinux/
> ^c drops me to a boot: prompt, enter takes me back.
> efi: locks up.
> legacy: pwd, ls and cat all have a slightly better console:
> the screen clears to black and the cursor homes:
> efi: it didn't clear and cursor is where it left off,
> which may be below the bottom of the screen.
> the cat ... SYSLX64.CFG runs off the bottom of the screen.
> hitting enter brings back the menu.)
> > Regards,
> > Ady.
> > PS: I am also hoping that the expectations are not to build a whole new
> > set of cfg files with all-working features for D-I here in the Syslinux
> > Mailing List (especially when developers upstream and downstream don't
> > care). Debian has been dropping support for Syslinux for years (from
> > installation/update scripts, themes and what not), and the same goes
> > for most distros and for The Syslinux Project itself, and nobody wanted
> > to "invest" the time when it was still relevant (with very few
> > exceptions, too-few).
> The existing legacy menus and help is fine, I would hope I can leave
> it mostly in place as it is.
The expectations regarding syslinux.efi are, unfortunately, too high.
If I would like to perform these tests by myself, it would take me much
less time than writing instructions and explaining every single detail
and reason for failures (such as: the boot menu should not be tested
with one entry only, whether in BIOS or in UEFI mode).
Moreover, years ago I already tested syslinux.efi and many of its
features. I stopped doing that, because The Syslinux Project is not
really actively developing anything.
Additionally, there are no indications that Debian would agree to
put/add/use anything related to Syslinux in UEFI. In fact, there are
hints of the opposite.
@Carl, even the original bug report in Debian's bug tracker that you
linked to in your original email has seen no relevant reply, and ATM
the info in there would only cause more confusion (because the info is
Considering that there are no signs of development upstream (i.e. The
Syslinux Project), and there are no signs of interest from downstream
in Debian (and in fact, all signs in both cases are pointing to the
opposite direction), I think it would be a waste of our time to keep
If developers for Syslinux and Debian were to show any minimal (real,
concrete) interest, I would gladly perform the tests and report the
More information about the Syslinux