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