Syslinux - Nov 2019 - CTRL+X LSS16 Image embedded in "DISPLAY message" no longer works?

Dear gentlemen,

this is just a marginal quirk...

I've been using a graphical logo at the pxelinux prompt in our LAN 
for many years. It's always been the same LSS16 picture, and it's 
always been working fine. 
I've been using pxelinux 3.53 until recently.
Right now I'm in the process of introducing "UEFI netboot" into
our
LAN, and also the diskless boot into Debian would make use of some 
goodies (variables) from modern pxelinux... hence my attempts to 
migrate my setup to pxelinux 6.03. I've downloaded a tarball with 
pre-built binaries.

Apart from other things, I've noticed in 6.03 that our graphical logo 
is no longer displayed, although the "DISPLAY message" text appears 
just fine.

I've also noticed in TFTPd logs that:

- while the boot.msg refers to ^Xcdlogo.lss, and this is what the old 
pxelinux 3.53 asks for via TFTP, 

- the new pxelinux 6.03 asks for a file called just "c", which 
obviously is not available...

- if I symlink or copy cdlogo.lss to "c", I believe pxelinux just 
hangs upon actually obtaining the file via TFTP :-)

I'm not conversant enough in the syslinux internals to know what 
changes have happend since 3.53 to the VGA video support, or to the 
routine loading that LSS file via TFTP. Quite a bit of water has 
probably flown under the bridge since 3.53.  I've noticed that some 
new SVGA support has been added and used for the new optional 
all-graphical menu (which I don't necessarily find very helpful for 
my specific setup).

Not exactly a painful issue, yet probably a regression...
Any comments would be welcome :-)

Last but not least: thanks to HPA and all the contributors for making 
syslinux possible.

Frank Rysanek

> I've been using a graphical logo at the pxelinux prompt in our LAN for
> many years. It's always been the same LSS16 picture, and it's
always
> been working fine. I've been using pxelinux 3.53 until recently. Right
> now I'm in the process of introducing "UEFI netboot" into our
LAN, and
> also the diskless boot into Debian would make use of some goodies
> (variables) from modern pxelinux... hence my attempts to migrate my
> setup to pxelinux 6.03. I've downloaded a tarball with pre-built
> binaries.
> 
> Apart from other things, I've noticed in 6.03 that our graphical logo
is
> no longer displayed, although the "DISPLAY message" text appears
just
> fine.
 
 
Problems - to say the least - with LSS16 images have been reported 
several times since the release of version 5. Unfortunately, there has 
been no improvement in the code that would solve these. That's under 
BIOS.

Under UEFI, not only that LSS16 images are not being displayed, but all 
sorts of inconsistencies regarding the boot screen(s) and the boot 
prompt have been reported too. Most of the rendering/displaying 
problems have not been resolved.

At any rate, to anyone attempting to use/test Syslinux (in any of its 
variants) from version 6+, I would suggest at least version 6.04-pre1, 
or, even better, the current binary packages from Debian Testing, over 
the possibility of using/testing 6.03.

Regards,
Ady.

On Wed, 2019-11-06 at 22:13 +0000, Ady Ady via Syslinux wrote:
>  
> Problems - to say the least - with LSS16 images have been reported 
> several times since the release of version 5. Unfortunately, there has 
> been no improvement in the code that would solve these. That's under 
> BIOS.
> 
> Under UEFI, not only that LSS16 images are not being displayed, but all 
> sorts of inconsistencies regarding the boot screen(s) and the boot 
> prompt have been reported too. Most of the rendering/displaying 
> problems have not been resolved.
> 
> At any rate, to anyone attempting to use/test Syslinux (in any of its 
> variants) from version 6+, I would suggest at least version 6.04-pre1, 
> or, even better, the current binary packages from Debian Testing, over 
> the possibility of using/testing 6.03.
> 
FWIW, I don't know if it is related to the problems that you mention, but I
did
notice that the standard strncat function was a bit buggy when I was working on
a patch recently. According to the documentation, strncat is supposed to null-
terminate the destination. From the man page:

"... As with strcat(), the resulting string in dest is always
null-terminated.
..."

The strncat function in Syslinux wasn't null-terminating the destination
though.
I think I was developing against 6.04-pre2.

FYI.