[syslinux] Some behaviors observed in recent versions

[Ady]

Testing the following (uncommon) syslinux.cfg with different Syslinux 
versions allows getting to several observations; some might be of 
interest to users, and some for the Syslinux developers.


 syslinux.cfg
 *** 
 UI menu.c32
 DEFAULT help
 TIMEOUT 30
 # ONTIMEOUT help
 LABEL pwd
 COM32 pwd.c32
 LABEL help
 MENU HELP help.txt
 *** 

1_ For the TIMEOUT-related directives to behave as expected, at least 
2 LABELs shall be present.
2_ Manually selecting "LABEL help" from the menu will display the 
content of "help.txt".
3_ Letting the DEFAULT or the ONTIMEOUT (when uncommented) directives 
automatically select "LABEL help" means that the core (not menu.c32) 
parses the "MENU HELP" directive, which of course fails (since the 
core parses MENU directives as comments, or disregards them, or does 
not understand them). The following tests take advantage of this 
known behavior so to trigger error messages.

4_ Using Syslinux 4.05 with the above cfg:
4.1_ The menu is displayed for 3 seconds; and then;
4.2_ An error message, "Invalid or corrupt kernel image", and the 
"boot:" prompt are displayed; and then;
4.3_ After 3 additional seconds the menu is displayed again (as the 
UI directive takes precedence).
4.4_ This whole cycle repeats itself until user intervention.


5_ Using Syslinux 4.05 with the above cfg but with ONTIMEOUT 
uncommented:
5.1_ The menu is displayed for 3 seconds; and then;
5.2_ An error message, "Invalid or corrupt kernel image", and the 
"boot:" prompt are displayed; and then;
5.3_ After 3 additional seconds, a _different_ error message, "Could 
not find kernel image: help", is displayed followed by the "boot:" 
prompt; and then;
5.4_ The step above, #5.3 alone, repeats itself until user 
intervention.


Observation #5.1: In Syslinux 4.05, once in CLI mode, the ONTIMEOUT 
directive takes precedence over the UI directive.

Observation #5.2: In this case ("ONTIMEOUT + MENU HELP help.txt"), 
there are 2 different error messages, depending on whether the menu 
or the CLI is used.


6_ Repeating test #4, with the above cfg but using Syslinux 
6.03-pre10:
6.1_ The menu is displayed for 3 seconds; and then;
6.2_ No error message is visible. The menu is displayed again, for 
the next 3 seconds, and the cycle repeats itself until user 
intervention.
6.3_ Pressing ESC twice we end up in the "boot:" prompt (first ESC) 
and the timer has no effect now (after the second ESC).
6.4_ Entering "help" in CLI we trigger the "LABEL help" entry. Since 
the CLI cannot parse a "MENU HELP help.txt" directive, we get a 
"Loading help... failed: No such file or directory", followed by the 
"boot:" prompt.
6.5_ After 3 seconds, the TIMEOUT directive kicks in, displaying the 
menu (again).
6.6_ Repeat step #6.3.
6.7_ Repeat step #6.4 but after the error message is displayed we 
press ESC once more, so the TIMEOUT is stopped, leaving us in the 
"boot:" prompt, where we can clearly still see the error message from 
attempting the "LABEL help" entry from CLI.


Observation #6.1: Note the different behavior comparing step #4.2 
with step #6.2.

Observation #6.2: In Syslinux 4.05, the error message is "Invalid or 
corrupt kernel image", while in Syslinux 6.03-pre10 the error message 
is "Loading help... failed: No such file or directory" (where "help" 
is the name of the "kernel image").

Observation #6.3: In Syslinux 4.05, the error message is visible, 
while in Syslinux 6.03-pre10 the error message might not be. In 
Syslinux 6.03-pre10, the behavior that a common user would see is 
just the menu being displayed again and again. In such condition, a 
user would need to know how to trigger a relevant error message from 
CLI.


7_ *Attempting* to repeat test #5, with the above cfg but with 
ONTIMEOUT uncommented, using Syslinux 6.03-pre10:
7.1_ The menu is displayed for 3 seconds; and then it is displayed 
again and again. At this point, the behavior is already different 
between Syslinux 4.05 and 6.03-pre10.
7.2_ Press ESC once, so to get to CLI. After the TIMEOUT (3 seconds), 
an error message, "Loading help... failed: No such file or directory" 
(where "help" is the "kernel image"), followed by the "boot:" prompt; 
and then;
7.3_ After 3 additional seconds, the _same_ error message, "Loading 
help... failed: No such file or directory", is displayed followed by 
the "boot:" prompt; and then;
7.4_ The step above, #7.3 alone, repeats itself until user 
intervention.


Observation #7.1: Note the different behavior comparing step #5.2 
with step #7.1.

Observation #7.2: In Syslinux 6.03-pre10 (same as in Syslinux 4.05), 
once in CLI mode, the ONTIMEOUT directive takes precedence over the 
UI directive.

Observation #7.3: In Syslinux 6.03-pre10 the error message is the 
same, whether the error is triggered by the menu parser or by the 
core. In Syslinux 4.05 the respective error messages were different.


8_ Testing the behavior of the SHIFT / ALT / CAPS LOCK / SCROLL LOCK 
keys during boot time (so to bypass the default "PROMPT 0") in 
Syslinux 4.05, the expected behavior is seen: instead of booting into 
the menu (UI directive), we boot into the "boot:" prompt.

9_ Testing the behavior of the SHIFT / ALT / CAPS LOCK / SCROLL LOCK 
keys during boot time (so to bypass the default "PROMPT 0") in 
Syslinux 6.03-pre10, all alternative keys fail. This bug is present 
since version 5.00. Note that I have not tested the "MENU SHIFTKEY" 
behavior, which is a different feature.


To be clear, I am not saying that the current behaviors are a problem 
(except for the last test #9); I am just pointing them out.

Hopefully this email might be of interest for some user(s). In some 
cases, users might just see a menu displayed again and again, 
covering up relevant error messages. In the future, web search 
engines might consider the Syslinux Mailing List as "active" again 
(as oppose to the current erroneous "dormant" state). Perhaps some 
documentation improvements could result from this. The behaviors 
described here might eventually catch the attention of the Syslinux 
developers, perhaps in relation to some (future) report. And perhaps 
the current bug in the "force-boot-prompt keys" could be resolved.

Regards,
Ady.