[syslinux] comments about 5.00pre10

[Matt Fleming]

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.

> 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.

> 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.

> 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?

> 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.

> 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.

> 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. 

> _ 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.

> _ 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.

> 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.

-- 
Matt Fleming, Intel Open Source Technology Center