[syslinux] comments about 5.00pre10

[Ady]

> On Wed, 2012-11-14 at 16:06 +0200, Ady wrote:
> > Hi Matt,
> > 
> > First comments about 5.00-pre10.
> > 
> > 1_ When using "ctrl+v" in the boot prompt, there is no space 
> > character between the version and the boot mode. Additionally, the 
> > main version number is shown twice.
> > For example, "SYSLINUX 5.00 5.00-PRE10CHS" should be:
> >  "SYSLINUX 5.00-PRE10 CHS"
> 
> This has always been the format. If you try the 4.06 release you will
> say that it is the same.
> 

Hmm, you might be right. I guess that presentation is related to any 
"special" build and the lack of space characters might be 
intentional. It still makes sense to improve it.

> > 2_ Boot to menu.c32, press [ESC] to go to the boot prompt. Pressing 
> > [ESC] once again returns back to the menu, as if [ENTER] would had 
> > been pressed. IIRC, in 4.06 the second [ESC] would not go back to the 
> > menu (meaning, it wouldn't execute the default label). In other 
> > words, [ESC] is acting as [ENTER].
> 
> Ouch. I *hate* this piece of code. I see what's happening. The old
> cmdline code in 4.06 discarded the ESC key, but in 5.00 because we share
> the cmdline code between ldlinux.c32 and the menu system, KEY_ESC is
> valid. I'll think about how to fix this properly.
> 
> > 3_ At the boot prompt, pressing [ENTER] (or [ESC], given the current 
> > mix up between both keys) should give the default kernel. For kernel 
> > images that return back to the boot prompt, repeating this behavior 
> > will eventually hang the prompt. The easiest way to reproduce this 
> > is:
> > 1. In syslinux.cfg, don't use UI nor DEFAULT (or comment out the 
> > lines).
> > 2. Boot. "No UI or DEFAULT configuration directives found!" will be 
> > shown and then the prompt.
> > 3. Press [ENTER] (or [ESC]...) several times, until it hangs.
> 
> Yeah, I can reproduce this. I'll look into it.
> 

I should correct my "until it hangs" statement. It _seems_ to hang, 
but if you press [ENTER] once again, it still responds. Anyway, the 
whole behavior needs to be corrected.

> > A similar bad behavior can be seen if the default label is any c32 
> > module that returns to the boot prompt. For example.
> > 
> >    *** start syslinux.cfg ***
> > 
> >  DEFAULT pwd1
> > 
> >  LABEL pwd1
> >  COM32 pwd.c32
> > 
> >    *** end syslinux.cfg ***
> > 
> > After booting, keep pressing [ENTER] once and again, until it fails. 
> > Moreover, one [ENTER] will execute the default label (pwd in the 
> > example), and the next one will just present the boot prompt (no 
> > default kernel execution). This behavior alternates until it hangs. 
> > (Hmm, could this be related to the leak that Shao is patching?)
> > 
> > 
> > 4_ About "win: Print error message if we fail to install to 
> > --directory". When running the (Windows-based) installer with 
> > "--directory" and the directory path doesn't exist in the destination 
> > device, the installer tries to use the "/" directory instead. Is this 
> > the correct expected behavior? I previously suggested that the 
> > installer should error out with "no such directory [exists]" or 
> > similar.
> 
> Well, it's the expected behaviour insofar as this is the way that it has
> always worked. I suppose if we fail to move the files we should delete
> the one from / too.
> 

I'm not sure about what you mean with "move the files".

"syslinux.exe --directory /boot/syslinux --install a:" (empty fat12 
formatted volume, so directory not yet created). The command errors 
out, as it should, but it still leaves ldlinux.sys on "a:/". Do you 
mean that the file(s) are first copied to the root of the volume and 
then moved to the "--directory"? If that's the case, maybe it should 
FIRST check for the existence of the destination directory (together 
with any other condition to be met), and only _then_ install the 
files if appropriate?


> > 5_ DISPLAY, F1-F12 doesn't work. I think SYSLINUX is not working 
> > correctly if no "UI [vesa]menu.c32" is used.
> 
> In what way does it not work?
> 

When I originally reported this, I really thought that it "simply 
doesn't work". Meaning, the content of the DISPLAY file is not being 
displayed at all, no matter what. The content of my testing DISPLAY 
file was only one line.

The (expected) behavior in 4.0x: when "UI menu.c32" is used, then 
"help.txt" will be displayed for a split second and then the menu 
appears. If [vesa]menu.c32 is not used (no UI directive), then 
"help.txt" is displayed above (before) the boot prompt. It seemed 
that it wasn't working in 5.00pre10.

But after additional tests, I now think the problem is elsewhere.

In short, I'll wait for the "false" MENU CLEAR issue (see report #7 
below) - or whatever is clearing (part of the) screen every time - to 
be resolved first, and then I'll re-test TIMEOUT (is it working at 
all?), DISPLAY, F1-F12, cat.c32 and others, with and without MENU 
CLEAR, and with and without "UI menu.c32".


> > 6_If message.txt is a DISPLAY file, then "cat.c32 message.txt" 
> > doesn't work. It may be happening with other files too, but at least 
> > "cat.c32 syslinux.cfg" works. I may be missing something here, but I 
> > don't know what.
> 
> How does it not work? It seems to work for me.
> 

Similar explanation as in #5 above.

> > 7_ When using menu.c32, the boot prompt behaves as if MENU CLEAR is 
> > always used. I previously reported this when testing menu.c32 to 
> > pwd.c32, but the same happens with any other image or even with 
> > [ESC].
> 
> OK, I'll look into this.
> 

And then I'll re-test the rest.

> > Status of the following?
> > 
> > _ When running an installer with "--version", the result doesn't 
> > include the "complete" version ("5.00-pre10")
> 
> Right, again this is a historical thing. It probably would make sense to
> include the prerelease tag. This is going to be pretty far down on the
> TODO list, however. 
> 

Sure.

> > _ Even though I changed to a different CWD, it still runs the 
> > commands without the need to type the path. Strange. It may be useful 
> > in some cases, and problematic in others.
> 
> How did you change the current work directory? Syslinux 5.00 includes a
> "PATH" variable that is similar to the one used by other command shells.
> It's default value is "/boot/syslinux:/boot", so if your command files
> are installed in either of these two paths, even if your cwd is
> somewhere else, Syslinux will find them.
> 

Well, regarding PATH,  the following questions, among others, should 
be answered in the documentation for 5.00 (if they will, then I don't 
need the answers now, so please don't waste your time on them now).

What happens if 2 images located in 2 different directories, with 
both directories being part of PATH, have the same name? What happens 
if 2 images have almost the same name, as image.c32 and image.bin for 
example? In which order the default PATH is searched for a matching 
image filename?  What's the default PATH when using variants other 
than SYSLINUX?

BTW, the default PATH seems to include "/" too.


> > _ The first argument for config.c32 works correctly, but the second 
> > (the soon-to-be new CWD) doesn't. The CONFIG directive from a menu 
> > seems to work (at least at first impression).
> 
> OK, I'll see what's wrong with this.
> 

I'll appreciate it. I should add that after the other behaviors I saw 
(the screen, or part of it, being cleared out), config.c32 might or 
might not be working correctly. Having part of the screen overwritten 
(while I didn't know it) could have been a potential factor 
influencing my conclusions about what works and what doesn't. In any 
case, I'll certainly re-test this after the next 5.00 pre-release.

> > Testing in a VBox VM:
> > 
> > _ hdt.c32:
> > Undef symbol FAIL: cpu_flags_strings
> 
> Hmm... right, that's because libcom32gpl.c32 isn't distributed with the
> Syslinux releases, and it's that library that the provides the
> 'cpu_flags_strings' symbol. I'll look into what we're supposed to do for
> hdt.c32 for the releases.
> 

Is this the same (or similar) for hello.c32? Or is the new hello.c32 
behavior the expected one?

TIA,
Ady.