[syslinux] efi vesamenu 6.03-pre

[Ady]

This is a bug report about Syslinux 6.03-pre11 in EFI.

To Syslinux EFI developers; the results can be replicated in real 
hardware.

I apologize for the length of the email; I am describing the steps 
necessary to reproduce the confusing behaviors the best I can.

I have been experimenting with VBox and Syslinux EFI32.

In EFI, the default screen resolution for [vesa]menu.c32 is not 640 x 
480 (and not 800 x600). This means that while using the same cfg 
file, a user might probably see a different screen presentation in 
BIOS than in EFI.

Once vesamenu.c32 is loaded, the output of executing a menu entry 
can't be *immediately* seen on screen; not always. I am having 
trouble explaining what I mean in generic terms, so here is an 
example.

 ***
 DEFAULT vesamenu.c32
 MENU CLEAR
 MENU BACKGROUND #A00000FF
 MENU CMDLINEROW 19
 MENU ENDROW 19
 LABEL pwd
 COM32 pwd.c32
 LABEL ls
 COM32 ls.c32
 ***

1_ Display vesamenu.

2_Keep pressing [enter]. One time it PWD, the next it shows the 
vesamenu again. Each time it PWD, the "boot:" prompt is displayed in 
a lower row. At some point, it will not be shown any longer. It 
behaves as if it would go on printing in lower rows each time.

And then...

3_ Pressing [enter] doesn't *show* the result (PWD).

4_ Pressing [esc] should show the "boot:" prompt, but it doesn't.

I don't *see* the "boot:" prompt on screen, but Syslinux behaves as 
in that state (if this expression makes any sense).

5_ At the "boot:" prompt (although I don't see it), pressing [ctrl]+L 
clears the screen and shows the "boot:" prompt. Since [ctrl]+L only 
works in CLI, it may be "tricky" to find the adequate state / moment 
(CLI, not vesamenu) where this keys combination works as necessary.

6_ The 'MENU ENDROW' value (and its expected behavior) seems to be 
ignored. Once booting the above vesamenu and pressing [enter], the 
first output (PWD) is shown over the vesamenu itself (not in row 19).

7_ Pressing [TAB] shows the command according to 'MENU CMDLINEROW' 
(row 19).
That means that the (to be executed) command itself is displayed on 
screen, and always in the same designated row, but the *result* of 
the command (e.g. actually seeing the resulting CWD on the "boot:" 
prompt) keeps moving down each time I execute an additional command.

8_ Additionally, the vesamenu entries are kept on screen. So the 
"moving" "boot:" prompt (and its corresponding result of each 
command) are "intertwined" by the text of the vesamenu itself, making 
it even more difficult to guess where on the screen the result is 
being displayed, and to be able to actually read that result.

9_ If all efi32 Syslinux modules are located in the CWD, executing 
the second entry, "ls", shows a partial list of the CWD.

9.1_ Since there are "too many" files to list in "one screen", ls.c32 
pauses, awaiting for the user to press [enter] so to continue 
displaying the list. This is expected, but in this efi32 VBox VM the 
rest of the list can't be actually seen. As it happened with the 
prior test with pwd.c32, the "boot:" prompt went "down" out of 
screen.

9.2_ Pressing [enter] again, the 'DEFAULT vesamenu.c32' command is 
executed, together with 'MENU CLEAR'.

9.3_ Pressing [enter] once more, the "pwd" entry is executed, but the 
result is not actually displayed (just as it happened in above 
tests).

Conclusion #9: the screen has been re-drawn, but the "boot:" prompt 
is still "down after" the available rows (28 rows for vesamenu). A 
new [ctrl]+L resets the "boot:" prompt row, allowing us to actually 
see the resulting CWD after the *next* "pwd" execution.

10_ From the "boot:" prompt, I can execute menu.c32. By repeating the 
tests I can see that the initial 'MENU ENDROW' is valid for menu.c32 
(as opposed to what happened in vesamenu.c32). But then the behavior 
is the same as in vesamenu: once the active row goes down (after its 
respective limit of 25/28 rows), it "keeps going down" (just as 
described above for vesamenu).

11_ Additionally, the menu is displayed not in the horizontal center 
of the screen, but leaning towards right-side. The menu is also 
displayed a little lower than the vesamenu, but this is expected.


All these behaviors are confusing (to common users like me, whether 
newcomers to Syslinux or with prior experience), and it took me 
several attempts to find out an adequate syslinux.cfg just to make 
some sense of them. These are not the behaviors seen in Syslinux 
4.xx.

These tests were performed with VBox efi32 and Syslinux 6.03-pre11 
(pre-built binaries from kernel.org), and it is possible that 
different versions of VBox could show different behaviors.

I have read reports of real EFI64 hardware (using the Syslinux 
6.03-pre1 
package in Debian Experimental) behaving in similar (confusing) ways. 
In my 
case, I knew what to expect according to my syslinux.cfg; users 
trying to use 
Syslinux EFI might probably see confusing behaviors.

Thank you,
Ady.