Syslinux - Aug 2015 - EFI: HP + syslinux = crash [ brown paper bag update ]

On Wed, Aug 5, 2015 at 3:03 PM, Oscar Roozen via Syslinux
<syslinux at zytor.com> wrote:
> Unfortunately I can't test anymore until Friday. Maybe gnu-efi got
> updated?  I seem to remember seeing a shell script pulling in the
> newest version during compilation...
It's version locked to a certain commit ID.

-- 
-Gene

>> Unfortunately I can't test anymore until Friday. Maybe gnu-efi got
>> updated?  I seem to remember seeing a shell script pulling in the
>> newest version during compilation...
>
> It's version locked to a certain commit ID.
Okay, so that's good. No worries there.

=== preamble ==
In this mail I talk about two different commits. To identify them 
furhter, they are:

|  commit 8702009fc7a6689432d17d4ea05d9c878452c57a
|  Author: Gene Cumm <gene.cumm at gmail.com>
|  Date:   Sun Jul 19 08:09:10 2015 -0400

This is the "latest and greatest" from the (offical?) git repository
on
git://repo.or.cz/syslinux.git.

|  commit e466d2498604c8eea055a8e98284d65311073b39
|  Author: Patrick Masotta <masottaus at yahoo.com>
|  Date:   Sat Aug 1 07:40:16 2015 -0400

This is (unoffical?) repository on git://github.com/geneC/syslinux.git 
to which I was referred by Gene in this mail:

   http://www.syslinux.org/archives/2015-August/023893.html

This commit solves the multinic bug that affected my test machine.

=== end ==
I made some progress on the crashing issue. You all were right, they are 
not related.

After the fix for multinic, vesalinux was the culprit. I probably messed 
up by mixing various versions of *.c32 modules, but right now commit 
e466d24 only crashes if I use vesamenu.c32 AND use a PNG for a 
background. If I comment out the PNG, the system boots fine. (ie. it 
really loads and runs the intended vmlinuz and initrd).

Now, there was this mystery why commit 8702009 crashed like it did the 
whole week and now doesn't crash anymore after I added some debugging 
code. Well, removing this debugging code did not make the crashes come 
back. It still did the same: it could not load ldlinux.e64 and it 
gracefully exited back to the firmware while reporting "Failed to load 
ldlinux.e64".  (The firmware then immediately clears the screen, so a 
human being without a capturing tool can't read it, but that's another 
story)

So.. something else must be the problem. Did I change something else in 
between?  Absolutely! I commented out this line in dhcpd.conf:

  option pxelinux.pathprefix
"http://10.X.255.254:8080/tftpboot/efi64/";

Put it back in => *crash*

Making the path very short ("http://x/") => *crash*

But when I leave out the http part => graceful exit.

Attached is a patch that works against both commits so you can see where 
the extra debugging output comes from. I also attach this debugging 
output from ILO4 leading up to the crash.

The good news is that e466d24 is not affected by this. It will nicely 
load ldlinux.e64 and *.c32 over http using this prefix.

So.. my conclusion for now:

8702009 crashed because of some http pathprefix bug
8702009 contains the multinic bug so wouldn't work anyway
e466d24 solves the mutlinic bug AND the http pathprefix bug
e466d24 kept crashing on me because I mixed up libraries from 8702009
e466d24 still has an issue with png's in vesalinux causing crashes

Is it time to update the official repository yet? ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipmi-crash.log
Type: text/x-log
Size: 3962 bytes
Desc: not available
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20150807/1e5d55d6/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: my-debug-pathes.diff
Type: text/x-patch
Size: 9190 bytes
Desc: not available
URL:
<http://www.zytor.com/pipermail/syslinux/attachments/20150807/1e5d55d6/attachment-0001.bin>

>>> 
 So.. my conclusion for now:
 
 8702009  crashed because of some http pathprefix bug
 8702009  contains the multinic bug so wouldn't work anyway
 e466d24  solves the mutlinic bug AND the http pathprefix bug
 e466d24  kept crashing on me because I mixed up libraries from 8702009
 e466d24  still has an issue with png's in vesalinux causing crashes
<<<

This is a good report. Thanks ! 

Anyone there knows what's the fix in e466d24 solving the http pathprefix
prefix issue?

Best,
Patrick

Updating myself again:

On 07-08-15 16:03, Oscar Roozen wrote:
 > e466d24 still has an issue with png's in vesalinux causing crashes

I can confirm this remaining crash is caused by the line "MENU 
BACKGROUND bootlogo.png".

The original bootlogo.png is 640x480. Forcing the videomode with "MENU 
RESOLUTION 640 480" did not resolve the crashes, nor did resizing the 
png to 1024x768 and forcing the mode to that size. If anyone wants to 
test or just admire this exact bootlogo.png, it is available for 
download at https://okkie.nu/tmp/bootlogo.png.

What did work, was resaving the logo as a jpg. This boots just fine.

According to the debug info, both videomodes initialized okay. The crash 
happens later. See these snippets of debug() output:

[640x480]
| Opening config file: pxelinux.cfg/category.default open_file 
pxelinux.cfg/category.default
| searchdir: pxelinux.cfg/category.default  root: 0x0000000000000000 
cwd: 0x0000000000000000
| PXE: file = 0x00000000772faaf8, retries left = 0: ok
| ok
| Hello, World! (initvesa.c)
| Hello, World! (vesa.c)
| mode 0 version 0 pixlfmt 1 hres=1024 vres=768
| mode_num = 0 query_status 0
| mode 0 hres=640 vres=480
| BGR8bit bpp 32 pixperScanLine 640 logical_scan 2560 bytesperPix 4
| Success setting mode 0
| Mode set, now drawing at 0x0000000091000000
| Ready!
| open_file bootlogo.png
| searchdir: bootlogo.png  root: 0x0000000000000000  cwd: 0x0000000000000000
| PXE: file = 0x00000000772faaf8, retries left = 0: ok
|  ^@ProLiant System BIOS P89 v1.40 (05/06/2015)
| (C) Copyright 1982 - 2015 Hewlett-Packard Development Company, L.P.


[1024x768]
| Opening config file: pxelinux.cfg/category.default open_file 
pxelinux.cfg/category.default
| searchdir: pxelinux.cfg/category.default  root: 0x0000000000000000 
cwd: 0x0000000000000000
| PXE: file = 0x00000000772faaf8, retries left = 0: ok
| ok
| Hello, World! (initvesa.c)
| Hello, World! (vesa.c)
| mode 0 version 0 pixlfmt 1 hres=1024 vres=768
| mode_num = 0 query_status 0
| mode 0 hres=640 vres=480
| mode_num = 1 query_status 0
| mode 1 hres=800 vres=600
| mode_num = 2 query_status 0
| mode 2 hres=1024 vres=768
| BGR8bit bpp 32 pixperScanLine 1024 logical_scan 4096 bytesperPix 4
| Success setting mode 2
| Mode set, now drawing at 0x0000000091000000
| Ready!
| open_file bootlogo1024.png
| searchdir: bootlogo1024.png  root: 0x0000000000000000  cwd: 
0x0000000000000000
| PXE: file = 0x00000000772faaf8, retries left = 0: ok
|  ^@ProLiant System BIOS P89 v1.40 (05/06/2015)

Setting the mode succeeds. The crash (reboot in this case) seems to 
happens during or after loading the PNG.

Here is a succesfull load of the bootlogo1024.jpg:
| BGR8bit bpp 32 pixperScanLine 1024 logical_scan 4096 bytesperPix 4
| Success setting mode 2
| Mode set, now drawing at 0x0000000091000000
| Ready!
| open_file bootlogo1024.jpg
| searchdir: bootlogo1024.jpg  root: 0x0000000000000000  cwd: 
0x0000000000000000
| PXE: file = 0x00000000772faaf8, retries left = 0: ok
| kernel is images/default-image/vmlinuz, args = 
initrd=images/default-image/initrd  rdblacklist=nouveau [...]

Even with vesa debugging turned on, this is all I can see.  The kernel 
line only appears after I select a menu entry of course.

For me this has a very low priority, as the jpg workaround is just fine. 
But maybe somebody wants to dig deeper, just bug me if you want more 
feedback.

 > Is it time to update the official repository yet? ;-)

Yeah! Found it at git://repo.or.cz/syslinux.git :-)