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.
