works with legacy, hangs with efi.
where works is:
No DEFAULT or UI configuration directive found!
but enter and ^v make things happen
hangs is: nothing happens, no response from keyboard, have to reboot.
note:
config prompt.cfg
prompt.cfg does not exist, but I would expect similar behaviour
between efi and legacy.
test is:
starting with blank image, mkfs, mount it...
+ cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi target/EFI/BOOT/BOOTX64.EFI
+ cp /usr/lib/syslinux/modules/efi64/ldlinux.e64 target/EFI/BOOT/LDLINUX.E64
+ cp /usr/lib/syslinux/modules/efi64/vesamenu.c32
/usr/lib/syslinux/modules/efi64/libcom32.c32
/usr/lib/syslinux/modules/efi64/libutil.c32
target/EFI/BOOT/SYSLINUX/EFI64
+ cp /usr/lib/syslinux/modules/bios/vesamenu.c32
/usr/lib/syslinux/modules/bios/libcom32.c32
/usr/lib/syslinux/modules/bios/libutil.c32 target/boot/syslinux/
+ sudo extlinux --install target/boot/syslinux/
target/boot/syslinux/ is device /dev/loop0
target
??? boot
? ??? syslinux
? ??? ldlinux.c32
? ??? ldlinux.sys
? ??? libcom32.c32
? ??? libutil.c32
? ??? syslinux.cfg
? ??? vesamenu.c32
??? EFI
??? BOOT
??? BOOTX64.EFI
??? LDLINUX.E64
??? SYSLINUX
? ??? EFI64
? ??? libcom32.c32
? ??? libutil.c32
? ??? vesamenu.c32
??? SYSLX64.CFG
# EFI/BOOT/SYSLX64.CFG
PATH /EFI/BOOT/SYSLINUX/EFI64/
default vesamenu.c32
label help
menu label ^Help
config prompt.cfg
# /boot/syslinux/syslinux.cfg
PATH /boot/syslinux/
default vesamenu.c32
label help
menu label ^Help
config prompt.cfg
https://salsa.debian.org/carlfk-guest/syslinux/blob/15fc479eb7ca5ab252ff6ff1fc94eb98d1ec31c9/tests/build_uefi_help.sh
--
Carl K
> works with legacy, hangs with efi. > > where works is: > No DEFAULT or UI configuration directive found! > but enter and ^v make things happen > > hangs is: nothing happens, no response from keyboard, have to reboot. > > note: > config prompt.cfg > prompt.cfg does not exist, but I would expect similar behaviour > between efi and legacy. > > test is: > starting with blank image, mkfs, mount it... > > + cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi target/EFI/BOOT/BOOTX64.EFI > + cp /usr/lib/syslinux/modules/efi64/ldlinux.e64 target/EFI/BOOT/LDLINUX.E64 > + cp /usr/lib/syslinux/modules/efi64/vesamenu.c32 > /usr/lib/syslinux/modules/efi64/libcom32.c32 > /usr/lib/syslinux/modules/efi64/libutil.c32 > target/EFI/BOOT/SYSLINUX/EFI64 > > + cp /usr/lib/syslinux/modules/bios/vesamenu.c32 > /usr/lib/syslinux/modules/bios/libcom32.c32 > /usr/lib/syslinux/modules/bios/libutil.c32 target/boot/syslinux/ > + sudo extlinux --install target/boot/syslinux/ > target/boot/syslinux/ is device /dev/loop0 > > target > ??? boot > ? ??? syslinux > ? ??? ldlinux.c32 > ? ??? ldlinux.sys > ? ??? libcom32.c32 > ? ??? libutil.c32 > ? ??? syslinux.cfg > ? ??? vesamenu.c32 > ??? EFI > ??? BOOT > ??? BOOTX64.EFI > ??? LDLINUX.E64 > ??? SYSLINUX > ? ??? EFI64 > ? ??? libcom32.c32 > ? ??? libutil.c32 > ? ??? vesamenu.c32 > ??? SYSLX64.CFG > > > # EFI/BOOT/SYSLX64.CFG > PATH /EFI/BOOT/SYSLINUX/EFI64/ > default vesamenu.c32 > label help > menu label ^Help > config prompt.cfg > > # /boot/syslinux/syslinux.cfg > PATH /boot/syslinux/ > default vesamenu.c32 > > label help > menu label ^Help > config prompt.cfg > > https://salsa.debian.org/carlfk-guest/syslinux/blob/15fc479eb7ca5ab252ff6ff1fc94eb98d1ec31c9/tests/build_uefi_help.sh > > -- > Carl KI thought that we would be discussing simplified (narrow) cases with the purpose of troubleshooting each issue, instead of mixing all the aspects of the whole setup together again. Anyway... Since you have no UI directive, you need at least DEFAULT and PROMPT directives (and, at least in the example you are providing here, you don't have the latter; in our prior discussion thread, you did have it). Also, it is highly recommended to use labels, not modules/commands, for the DEFAULT command. The third issue is that the PATH directive is using absolute paths. The buggy PATH directive doesn't understand absolute paths correctly ATM. My prior email was long, but not _that_ unclear in this regard. Additionally, your setup for BIOS and for UEFI in this example are not "the same". In BIOS, you are using the same directory for the cfg file and for the c32 modules (the same as your WD), whereas in UEFI, the cfg file is in your WD, and your c32 modules are located in a different directory. Considering the aforementioned differences and issues, it is not a surprise that you get different behaviors. Testing simplified setups would had helped you see each of these issues separately. Finally, you are using vesamenu.c32, without a background. In BIOS, although possibly slightly "ugly" in the eyes of some users, it can still work as expected - it is "usable". UEFI in contrast, has several problems with it: _ in UEFI, the default vesamenu.c32 colors / contrast is not only "ugly", but rather very unclear for the user; _ as oppose to BIOS, the screen doesn't "clear / clean" correctly. Try "[CTRL]+[L]" from the boot prompt under BIOS and under UEFI and see the difference, and/or use MENU CLEAR and see the different behavior between BIOS vs. UEFI from the menu (this is probably the worst matter in terms of usage); _ in many UEFI implementations, the support for a screen resolution of 640x480 is "flaky" at best, and thus, the default vesamenu.c32 behavior under UEFI is very "unfriendly", to say the least. Using the 'MENU RESOLUTION' directive might help for some UEFI cases/implementations, but the "splash" background file should also match the same setting. See: www.syslinux.org/wiki/index.php/Menu#MENU_RESOLUTION One thing you could try is to test menu.c32 (not vesa*) under UEFI (after "solving" the other issues I mentioned above). The same issues as for vesamenu.c32 in UEFI are relevant, but the default colors and presentation are different, so testing it might help towards deciding which default configuration/setup is more adequate for UEFI. So, unfortunately, the short answer is "no"; since your setup under BIOS is not "the same" as in UEFI, and each firmware has its pros and cons, it is not a surprise that the resulting behavior in this case is not the same. Regards, Ady.
On Thu, Dec 6, 2018 at 5:14 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > works with legacy, hangs with efi. > > > > where works is: > > No DEFAULT or UI configuration directive found! > > but enter and ^v make things happen > > > > hangs is: nothing happens, no response from keyboard, have to reboot. > > > > note: > > config prompt.cfg > > prompt.cfg does not exist, but I would expect similar behaviour > > between efi and legacy. > > > > test is: > > starting with blank image, mkfs, mount it... > > > > + cp /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi target/EFI/BOOT/BOOTX64.EFI > > + cp /usr/lib/syslinux/modules/efi64/ldlinux.e64 target/EFI/BOOT/LDLINUX.E64 > > + cp /usr/lib/syslinux/modules/efi64/vesamenu.c32 > > /usr/lib/syslinux/modules/efi64/libcom32.c32 > > /usr/lib/syslinux/modules/efi64/libutil.c32 > > target/EFI/BOOT/SYSLINUX/EFI64 > > > > + cp /usr/lib/syslinux/modules/bios/vesamenu.c32 > > /usr/lib/syslinux/modules/bios/libcom32.c32 > > /usr/lib/syslinux/modules/bios/libutil.c32 target/boot/syslinux/ > > + sudo extlinux --install target/boot/syslinux/ > > target/boot/syslinux/ is device /dev/loop0 > > > > target > > ??? boot > > ? ??? syslinux > > ? ??? ldlinux.c32 > > ? ??? ldlinux.sys > > ? ??? libcom32.c32 > > ? ??? libutil.c32 > > ? ??? syslinux.cfg > > ? ??? vesamenu.c32 > > ??? EFI > > ??? BOOT > > ??? BOOTX64.EFI > > ??? LDLINUX.E64 > > ??? SYSLINUX > > ? ??? EFI64 > > ? ??? libcom32.c32 > > ? ??? libutil.c32 > > ? ??? vesamenu.c32 > > ??? SYSLX64.CFG > > > > > > # EFI/BOOT/SYSLX64.CFG > > PATH /EFI/BOOT/SYSLINUX/EFI64/ > > default vesamenu.c32 > > label help > > menu label ^Help > > config prompt.cfg > > > > # /boot/syslinux/syslinux.cfg > > PATH /boot/syslinux/ > > default vesamenu.c32 > > > > label help > > menu label ^Help > > config prompt.cfg > > > > https://salsa.debian.org/carlfk-guest/syslinux/blob/15fc479eb7ca5ab252ff6ff1fc94eb98d1ec31c9/tests/build_uefi_help.sh > > > > -- > > Carl K > > I thought that we would be discussing simplified (narrow) cases with > the purpose of troubleshooting each issue, instead of mixing all the > aspects of the whole setup together again. Anyway...I'm trying to just examine config prompt.cfg If you want me to do something else, I need more direction than "start a new thread" ;)> > Since you have no UI directive, you need at least DEFAULT and PROMPT > directives (and, at least in the example you are providing here, you > don't have the latter; in our prior discussion thread, you did have > it). > > Also, it is highly recommended to use labels, not modules/commands, for > the DEFAULT command.should I change something for this test? (or abandon this and go back to step by step building a working system)> > The third issue is that the PATH directive is using absolute paths. The > buggy PATH directive doesn't understand absolute paths correctly ATM. > My prior email was long, but not _that_ unclear in this regard.# EFI/BOOT/SYSLX64.CFG PATH SYSLINUX/EFI64/ default vesamenu.c32 no help, still hangs.> > Additionally, your setup for BIOS and for UEFI in this example are not > "the same". In BIOS, you are using the same directory for the cfg file > and for the c32 modules (the same as your WD), whereas in UEFI, the cfg > file is in your WD, and your c32 modules are located in a different > directory. > > Considering the aforementioned differences and issues, it is not a > surprise that you get different behaviors. Testing simplified setups > would had helped you see each of these issues separately.I can see that, but I'm not sure what I should do. I'm using the structure you suggested. I'm not sure what to change to bring the two inline.> > Finally, you are using vesamenu.c32, without a background. In BIOS, > although possibly slightly "ugly" in the eyes of some users, it can > still work as expected - it is "usable". UEFI in contrast, has several > problems with it: > > _ in UEFI, the default vesamenu.c32 colors / contrast is not only > "ugly", but rather very unclear for the user;they are both visually the same. http://imgr.sytes.net/a/qemu_b1.png http://imgr.sytes.net/a/qemu_b2.png If this surprises you, I'll try to find why - maybe one of the debian patches.> > _ as oppose to BIOS, the screen doesn't "clear / clean" correctly. Try > "[CTRL]+[L]" from the boot prompt under BIOS and under UEFI and see the > difference, and/or use MENU CLEAR and see the different behavior > between BIOS vs. UEFI from the menu (this is probably the worst matter > in terms of usage); > > _ in many UEFI implementations, the support for a screen resolution of > 640x480 is "flaky" at best, and thus, the default vesamenu.c32 behavior > under UEFI is very "unfriendly", to say the least. Using the 'MENU > RESOLUTION' directive might help for some UEFI cases/implementations, > but the "splash" background file should also match the same setting. > See: > > www.syslinux.org/wiki/index.php/Menu#MENU_RESOLUTION > > One thing you could try is to test menu.c32 (not vesa*) under UEFI > (after "solving" the other issues I mentioned above). The same issues > as for vesamenu.c32 in UEFI are relevant, but the default colors and > presentation are different, so testing it might help towards deciding > which default configuration/setup is more adequate for UEFI. >for now I'll be happy with "doesn't crash" ;)> > So, unfortunately, the short answer is "no"; since your setup under > BIOS is not "the same" as in UEFI, and each firmware has its pros and > cons, it is not a surprise that the resulting behavior in this case is > not the same.I included the legacy files to vet that my cfg file was sane, but sounds like that isn't a good test, so should I remove all the legacy support from my tests to keep things simpler?> > Regards, > Ady. > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux-- Carl K