[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