[syslinux] efi config hang

Tue Dec 11 17:27:43 PST 2018

On Tue, Dec 11, 2018 at 11:40 AM Ady Ady via Syslinux
<syslinux at zytor.com> wrote:
>
>
> > 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).

I was all set to do this and found:

authored 1 month ago by Holger Wansing
- f0 ${SYSDIR}f10.txt
+ f10 ${SYSDIR}f10.txt
https://salsa.debian.org/installer-team/debian-installer/commit/935324cb0b98f261fc2dae1a024b71bb0678ffd4

>
>
> > > > _ 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.

I see the effects, both good and bad.  I'm having trouble knowing how
bad the bad is.

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

I'm not really worried about text displaying correctly (or at all) as
long as it doesn't seem to be hung.

>
>
> > > > _ 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.

I'm only interested in this case if it helps fix something I do care about.

And right now I don't really have a list of what I think needs fixing.
but I am getting there.

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

that's fine.

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

I think so too.

>
> 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).

Now might be a good time to fix this.  I have someones ear that will
likely accept simple patches.

> (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.

This may be something I don't care about.

>
>
> > 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).

I just noticed the "or all" in this:

"...any of the respective config files (or even all of them) — namely
isolinux.cfg, and/or extlinux.conf, and/or syslinux.cfg — can
optionally be located together in the same "/[[boot/]syslinux/]"
directory."
https://www.syslinux.org/wiki/index.php?title=Configuration_location_and_name

My current plan is to put together an hd-media/boot.img that one would
expect to work based on the docs.
I think I need to move all the legacy binaries into boot/syslinux
leave the config files in /
and have a boot/syslinux/syslinux.cfg that links to /menu.cfg

and see if legacy still works

breaking legacy boot is a blocker.

>
> Regards,
> Ady.
>
>
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux

--
Carl K