On 8/4/17, Ady Ady via Syslinux <syslinux at zytor.com> wrote:> >> Note, I am using syslinux from Ubuntu 16.04.2, presume that is 6.03. >> >> Regards, >> Barry > > Before investing time in replying to each different (unexpected) > behavior, I would suggest testing with *pre-built* binaries from > 6.04-pre1 downloaded from kernel.org (considering the lack of package > maintenance). > > Reminder: *all* (used) syslinux-related binaries pertaining to the > relevant platform (e.g. BIOS) shall match the same version and build > (and platform). For instance, if you want to test 6.04-pre1 pre-built > binaries, you need to use matching lib*.c32 library module files, > ldlinux.*, menu.c32 (among other used c32 modules), executing the > matching installer executable, etc, (all originated from the same > ".bios/*" directory tree of the official distribution archives). > > After reporting back the resulting behavior with the pre-built > binaries, we'll see which issues actually remain relevant. > > @Barry, would you be able to perform such test? >Thanks for the response. Yep, done. I downloaded from kernel.org 6.04-pre1, and compiled it. I made certain only using those files. With menu.c32, as per my example, reproducing here: ui menu.c32 menu title Easy Boot Manager default quirky timeout 100 label quirky menu label Easy 0.2.6 kernel vmlinuz append root=/dev/sda3 rootwait rw label Help menu help help.msg I still get the previous screen showing through on the background. I have taken a couple of photos. The first is when I select the help, and second when I hit Esc key and go back to the menu. Note, this is booting on a 64-bit UEFI-firmware PC, in a esp fat32 partition. Photos are here: http://distro.ibiblio.org/quirky/quirky6/project/temp/ Regards, Barry
> On 8/4/17, Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > > Thanks for the response. Yep, done. I downloaded from kernel.org > 6.04-pre1, and compiled it. I made certain only using those files.FWIW and just FTR, I suggested the pre-built binaries already included in the official archives. If I were to suggest compiling anew, I would had pointed to the current git master head located at: repo.or.cz/syslinux.git and to: www.syslinux.org/wiki/index.php/Building At any rate, in this particular case (see below) it wouldn't had produced any difference.> > Note, this is booting on a 64-bit UEFI-firmware PC, in a esp fat32 partition. >Aha! The platform (UEFI, x64) is very relevant. There are several problems regarding the boot screen under UEFI. One of them is the (default) screen resolution being supported by each particular firmware implementation. Another one is menu.c32 (as opposed to vesamenu.c32) being supported (or not) by each particular firmware implementation. And there is also the screen refresh problem under UEFI, which is the issue that you are experiencing now. I reported the screen's "refresh" issue(s) under UEFI several years ago. For example, while in the boot prompt CLI, pressing [CTRL+L] should "home" the prompt (i.e. move it to the upper left corner of the screen) and clear the screen. Under UEFI, the boot prompt goes to home, but it fails to clear the screen. There are 3 procedures to clear the boot screen: _ [CTRL+L] keyboard combination in CLI. _ Within boot help message (aka "DISPLAY") files, the "ASCII 12" character should also clear the screen. When this is used, it is usually the very first character in the msg file, but not always (e.g. in Barry's help.msg file, it isn't). _ When using (vesa)menu.c32, the 'MENU CLEAR' directive is supposed to clear the screen when the configuration file is parsed. As I reported several years ago, whichever method (of the above three) is used, it (currently?) fails under UEFI. @Barry, One potential alternative would be to use less rows in the menu, leaving space to display text at the lowermost area of the screen, but such text can only use one (electable) color (in contrast to the msg files, which can display each character in a different color). IMHO, this alternative does not worth the time for this particular project. Since you are using only 2 menu entries, would you consider the possibility of using the msg file(s) and the boot prompt, while avoiding the use of (vesa)menu.c32 for this particular project? If you do, there is room for improvements. FYI: _ [CTRL+L]: www.syslinux.org/wiki/index.php?title=Cli#Keystrokes www.syslinux.org/wiki/index.php?title=Directives/special_keys _ MENU CLEAR: www.syslinux.org/wiki/index.php?title=Menu#MENU_CLEAR _ ASCII 12: www.syslinux.org/wiki/index.php?title=Display_file_format Regards, Ady.
On 8/5/17, Ady Ady via Syslinux <syslinux at zytor.com> wrote:> Since you are using only 2 menu entries, would you consider the > possibility of using the msg file(s) and the boot prompt, while > avoiding the use of (vesa)menu.c32 for this particular project? If you > do, there is room for improvements. > >Thanks for the info. Yes, I previously did not have a menu, for Puppy Linux and Quicky. It is only now I am considering a menu. The example I gave was just an example, I am thinking of more menu entries. For example: This is using vesamenu.c32, example /EFI/BOOT/syslinux.cfg: ----------- ui vesamenu.c32 menu title Easy OS default normal timeout 100 label normal menu label Normal startup kernel ../../vmlinuz append root=/dev/sda3 rootwait rw label nox menu label Commandline only, do not start X kernel ../../vmlinuz append root=/dev/sda3 rootwait rw qfix=nox label fsck menu label Filsystem check of working partition kernel ../../vmlinuz append root=/dev/sda3 rootwait rw qfix=fsck label bak menu label Rollback to previous snapshot kernel ../../vmlinuz append root=/dev/sda3 rootwait rw qfix=bak --------------- As I mentioned in the first post, there is a different problem when using vesamenu.c32, a blinking cursor to left of the menu. Here is a photo: http://distro.ibiblio.org/quirky/quirky6/project/temp/syslinux-vesamenu.jpg ...it blinks black and white. Regards, Barry