[syslinux] EFI: HP + syslinux = crash
Ady
ady-sf at hotmail.com
Thu Aug 6 09:47:27 PDT 2015
>
> I am trying to find out whether vesamenu.c32 was crashing or the code
> that was loading/starting vesamenu.c32. I haven't found that out yet.
For testing this case with vesamenu.c32 I would suggest a very simple
cfg with 2 or 3 entries (not just one entry, as the behavior would be
slightly different) as first step.
For example:
*** syslinux.cfg start ***
# Note that labels are not using the same name as actual files, in
purpose.
DEFAULT pwdlabel
LABEL pwdlabel
COM32 pwd.c32
LABEL lslablel
COM32 ls.c32
*** syslinux.cfg end ***
For a KISS troubleshooting, *all* the c32 files should be located
together, in the root of the filesystem, where syslinux.efi and
ldlinux.e64 (for EFI x86_64) should be located too.
Note that all the Syslinux-related files should come from the same
exact build.
With the above syslinux.cfg, you should be booting to the Syslinux
"boot:" prompt and immediately you should see the result of pdw.c32,
and then back to the prompt.
At that point, type-in vesamenu.c32 [enter]. If / when everything works
as expected, you should see a (not-so-appealing and possibly with an
inadequate screen resolution) vesamenu. But, in practice, other things
could happen instead:
_ Vesamenu attempts to show a menu, but your UEFI's GOP or UGA
(whichever one of those your particular firmware supports) might not
support the default screen resolution of vesamenu.c32, 640X480. There
is a chance that your UEFI might not even support 800 x 600 either.
_ From the prior possibility, after pressing [enter] you might or might
not be able to see the result of pwd.c32 and the boot prompt.
_ Or maybe vesamenu.c32 might crash at some point; when it is loading
the menu, or when you try to execute one of the menu entries, or when
exiting from the c32 module back to the boot prompt.
A reminder: (vesa)menu.c32 uses a different parser than the CLI.
The next step would be to add 'MENU RESOLUTION' with relevant values in
syslinux.cfg and test several standard resolutions (including 'MENU
RESOLUTION 1024 768', even if your screen is not 4:3).
Whether there is some improvement at this point or not, only now (after
all prior tests) I would also add a matching MENU BACKGROUND directive.
When I say "matching", I mean that the values used for the 'MENU
RESOLUTION' directive shall match the resolution used in the background
image.
Additional tests could include testing whether a png background behaves
the same as a jpg file; always with the adequate resolution according
the values in the MENU RESOLUTION directive being used in each test.
>
> > What do you mean with "nope"? I think I saw some IPAPPEND somewhere; am
> > I wrong? Am I mixing email threads (again)?
>
> No you're right. Is IPAPPEND family of SYSAPPEND? I'm not so fluent in
> syslinux configuration yet. And I just discovered how loading just
> menu.c32 instead of vesamenu.c32 stopped the machine from crashing. I
> really haven't had time to dig deeper into the 'why' since discovering
> this. I also understand that I need to learn more about the
> configuration parser now..
First, see my reminder above about having different parsers in
Syslinux.
Regarding IPAPPEND / SYSAPPEND, see:
http://www.syslinux.org/wiki/index.php/Config#SYSAPPEND
>
>
> > Or perhaps you meant that you have triple-checked and thoroughly tested
> > that strange behavior we saw last month regarding some "space-like
> > characters" and concluded, without a doubt, that such problem does not
> > exist in your scenario / hardware?
>
> Uh oh... more reading to do for me. I did not fully understand your
> question there.
>
> But the menu entry is working. If syslinux starts and menu.c32 loads,
> all menu entries work perfectly fine. No crashing there. Is IPAPPEND
> or "space-like characters" (whatever these are) still relevant?
There were discussions (and patches) related to this "space-like
characters" about a month ago or so. I'm not sure you would be
interested (or have the time) now for the prior conversation about the
matter. There are additional places where the code might need some
similar reviewing (IIRC, no less than 5 lines, and up to 20 perhaps).
Let me emphasize the term *review* (with a pair of eyes, a brain, and
some relevant knowledge, or whichever alternatives are available);
whether there is a real need for patches about the issue, I do not
know.
>
> And now, just before I had to leave the office to return only on
> Friday, I found that most crashes mysteriously disappeared. Go
> figure... I *really* want to dive into it now, but I can't..
Considering that Syslinux itself is booting in your system now, you
might be interested in debug.c32, to be executed with relevant
arguments before launching your kernel (or before any kind of image /
module for these tests). See:
http://www.syslinux.org/wiki/index.php/Development/Debugging#Syslinux_Dy
namic_Debugger
Regards,
Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>
More information about the Syslinux
mailing list