[syslinux] EFI: HP + syslinux = crash

[Oscar Roozen]

On 05-08-15 10:01, Patrick Masotta wrote:
>>>>
>   Okay, the code in efi/ uses Print() from gnu_efi, but generic code from
>   core/ like core/elflink/load_env32.c prints their messages and debugging
>   stuff using printf(). These messages end up nowhere. This may explain
>   why I never saw anything beyond a certain point, even with debugging
>   turned on.
>   <<<
>
> isn't it redirected at all??

No. If, for example, I change:

         dprintf("Starting %s elf module subsystem...\n", ELF_MOD_SYS);

into regular printf(), I don't see the result in my ipmi-logs nor on my 
screen. If I change it to Aprint() (and %s into %a) then I do see the 
message.

To make sure it isn't overwritten before I see it, I put a while(1) in 
front, so it will end in an endless loop printing this message.

Maybe we need to explicitly redirect stdout and stderr to the console 
under EFI on some firmware?



>>>>
>   I was busy adding some code to dprintf.h to add a wrapper that converts
>   the dprintf calls to a APrint("%a", buf) calls when I got an idea... The
>   ILO4 environment provides a virtual COM2 port. I was reluctant to
>   hook  something to COM1 as I have to order some hardware for that, but this
>   also works very well. A pity I didn't think of using it earlier.
>   <<<
>
> You can set the com address for debugging (com1/com2/ whatever) if you like

I was originally looking for a way to debug to the console instead. 
Defining DEBUG_STDIO did not help. Now I know why.

> Are you still loading PNGs?
> Have you tried vesamenu w/o a background image?

No and yes. I removed all fancy stuff, leaving just:


	LABEL linux
	  KERNEL path/to/vmlinuz
	  IPAPPEND 3
	  APPEND initrd=path/to/initrd  rdblacklist=nouveau
	  MENU LABEL ^AUTO       - Normal node boot
	  MENU DEFAULT
	
	[.. some more entries ..]
	
	DEFAULT vesamenu.c32
	PROMPT 0
	TIMEOUT 50
	MENU TITLE Cluster Manager PXE Environment (EFI64)

With the default being either vesamenu.c32 or menu.c32.

Using menu.c32 i can sucessfully boot this kernel into a running system.


> when you do not see the transfer of ldlinux.e64 the chances are you are suffering the multi-nic bug.
> If you see "anything" after syslinux.efi transferred correctly that tells us the multi-nic bug is gone and
> there might be something else going on now.

See my message to Gene a few minutes ago. My guess is that the problems 
itself are not the reason to crash, but the exit-code or error-reporting 
code is the one doing the crashing.