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
First, I'm confused. In the prior "whole" setup (the one you generated after my 15 steps, plus one workaround), was/is the basic boot menu at least "working" when you used the workaround for the buggy PATH directive when booting in UEFI mode? I mean: "PATH EFI/BOOT/SYSLINUX/EFI64/" in "target/EFI/BOOT/SYSLX64.CFG". It is not perfect, but at least it should show the boot menu in UEFI mode, and not hang immediately. Could you please confirm? Regarding the "prompt.cfg" you are now trying to investigate (which is not the one in boot.img), the following is (potentially) the first in a series of simple, iterative, progressive tests and feedback. And no, I'm not going to just write the ending/working result, in particular when I don't know/understand the new goal. If we don't know what is wrong/failing, then we need "basic" step by step testing (iterations) for troubleshooting. Using 6.04~git20171011.af7e95c3+dfsg1-6 packages from Debian Unstable for all syslinux-related files. target ??? EFI ??? BOOT ??? BOOTX64.EFI ??? LDLINUX.E64 ??? libcom32.c32 ??? libutil.c32 ??? vesamenu.c32 ??? pwd.c32 ??? ls.c32 ??? cat.c32 ??? SYSLX64.CFG All in the same dir, we don't change WD, we don't mix it with BIOS, we don't need the crappy PATH directive. ### EFI/BOOT/SYSLX64.CFG start ### # Note that there is no "splash.png" background # This is a command UI vesamenu.c32 # The DEFAULT should rather be a label, not a command DEFAULT vesamenulabel # If we have an active ("uncommented") UI directive, # then the PROMPT directive makes no diff. # This command is here anyway, in purpose. PROMPT 1 # Let's try to clear the screen when we load the menu MENU CLEAR LABEL vesamenulabel COM32 vesamenu.c32 LABEL pwdlabel COM32 pwd.c32 LABEL lslabel COM32 ls.c32 LABEL catlabel COM32 cat.c32 APPEND /EFI/BOOT/SYSLX64.CFG # To be tested from the boot prompt, using a different label LABEL vesamenulabel2 COM32 vesamenu.c32 APPEND SYSLX64.CFG ### EFI/BOOT/SYSLX64.CFG end ### The result might not be a nice, readable screen, but it should not hang nor give errors about vesamenu.c32. Could you please confirm this (too)? Could you also please try the "equivalent" (not exactly the same, but similar) to the above simple UEFI-only setup in a separate BIOS-only case? I hope by now you can see which small details are relevant in order to "translate" from one platform to the other. Regards, Ady. PS: I am also hoping that the expectations are not to build a whole new set of cfg files with all-working features for D-I here in the Syslinux Mailing List (especially when developers upstream and downstream don't care). Debian has been dropping support for Syslinux for years (from installation/update scripts, themes and what not), and the same goes for most distros and for The Syslinux Project itself, and nobody wanted to "invest" the time when it was still relevant (with very few exceptions, too-few).
On Thu, Dec 6, 2018 at 10:00 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > First, I'm confused. In the prior "whole" setup (the one you generated > after my 15 steps, plus one workaround), was/is the basic boot menu at > least "working" when you used the workaround for the buggy PATH > directive when booting in UEFI mode? I mean: > > "PATH EFI/BOOT/SYSLINUX/EFI64/" > > in > > "target/EFI/BOOT/SYSLX64.CFG". > > It is not perfect, but at least it should show the boot menu in UEFI > mode, and not hang immediately. > > Could you please confirm?It did show the boot menu, I can use the arrow keys to navigate the menu, I can select the installer and it runs If I select "Help" and enter, or tab and enter, it hangs. help, tab, enter hang: http://imgr.sytes.net/a/qemu_b3.png And.. in trying to verify syslinx version, I have found another hang: efi boot, see menu, hit ^c, hung. legacy boot, ^c gets me a boot: prompt.> > > Regarding the "prompt.cfg" you are now trying to investigate (which is > not the one in boot.img), the following is (potentially) the first in a > series of simple, iterative, progressive tests and feedback. And no, > I'm not going to just write the ending/working result, in particular > when I don't know/understand the new goal.prompt.cfg is the Help option from the debian installer boot.img.> > > If we don't know what is wrong/failing, then we need "basic" step by > step testing (iterations) for troubleshooting. > > Using 6.04~git20171011.af7e95c3+dfsg1-6 packages from Debian Unstable > for all syslinux-related files. > > target > ??? EFI > ??? BOOT > ??? BOOTX64.EFI > ??? LDLINUX.E64 > ??? libcom32.c32 > ??? libutil.c32 > ??? vesamenu.c32 > ??? pwd.c32 > ??? ls.c32 > ??? cat.c32 > ??? SYSLX64.CFGtarget ??? EFI ??? BOOT ??? BOOTX64.EFI ??? cat.c32 ??? LDLINUX.E64 ??? libcom32.c32 ??? libutil.c32 ??? ls.c32 ??? pwd.c32 ??? SYSLX64.CFG ??? vesamenu.c32> > All in the same dir, we don't change WD, we don't mix it with BIOS, we > don't need the crappy PATH directive. > > ### EFI/BOOT/SYSLX64.CFG start ### > > # Note that there is no "splash.png" background > > # This is a command > UI vesamenu.c32 > > # The DEFAULT should rather be a label, not a command > DEFAULT vesamenulabel > > # If we have an active ("uncommented") UI directive, > # then the PROMPT directive makes no diff. > # This command is here anyway, in purpose. > PROMPT 1 > > # Let's try to clear the screen when we load the menu > MENU CLEAR > > LABEL vesamenulabel > COM32 vesamenu.c32 > > LABEL pwdlabel > COM32 pwd.c32/EFI/BOOT/> > LABEL lslabel > COM32 ls.c32 >[dir] . LDLINUX.E64 libcom32.c32 menu.c32 boot: BOOTX64.EFI cat.c32 ls.c32l.c32 pwd.c32> LABEL catlabel > COM32 cat.c32 > APPEND /EFI/BOOT/SYSLX64.CFG >(dumps this file to the screen)> # To be tested from the boot prompt, using a different label > LABEL vesamenulabel2 > COM32 vesamenu.c32 > APPEND SYSLX64.CFG^c screen clears system seems to hang. I see no cursor, enter, ^v, nothing seems responsive.> > ### EFI/BOOT/SYSLX64.CFG end ### > > The result might not be a nice, readable screen, but it should not hang > nor give errors about vesamenu.c32. > > Could you please confirm this (too)? > > Could you also please try the "equivalent" (not exactly the same, but > similar) to the above simple UEFI-only setup in a separate BIOS-only > case? I hope by now you can see which small details are relevant in > order to "translate" from one platform to the other.copied the files from bios into $target/boot/syslinux/ copied/renamed the .cfg file (no changes needed) cp \ /usr/lib/syslinux/modules/bios/vesamenu.c32 \ /usr/lib/syslinux/modules/bios/libcom32.c32 \ /usr/lib/syslinux/modules/bios/libutil.c32 \ /usr/lib/syslinux/modules/bios/ls.c32 \ /usr/lib/syslinux/modules/bios/cat.c32 \ /usr/lib/syslinux/modules/bios/pwd.c32 \ $target/boot/syslinux/ cp $target/EFI/BOOT/SYSLX64.CFG $target/boot/syslinux/syslinux.cfg sudo extlinux --install $target/boot/syslinux/ differences: ^c drops me to a boot: prompt, enter takes me back. efi: locks up. legacy: pwd, ls and cat all have a slightly better console: the screen clears to black and the cursor homes: http://imgr.sytes.net/a/qemu_b5.png efi: it didn't clear and cursor is where it left off, http://imgr.sytes.net/a/qemu_b4.png which may be below the bottom of the screen. the cat ... SYSLX64.CFG runs off the bottom of the screen. http://imgr.sytes.net/a/qemu_b6.png hitting enter brings back the menu.)> > Regards, > Ady. > > PS: I am also hoping that the expectations are not to build a whole new > set of cfg files with all-working features for D-I here in the Syslinux > Mailing List (especially when developers upstream and downstream don't > care). Debian has been dropping support for Syslinux for years (from > installation/update scripts, themes and what not), and the same goes > for most distros and for The Syslinux Project itself, and nobody wanted > to "invest" the time when it was still relevant (with very few > exceptions, too-few).The existing legacy menus and help is fine, I would hope I can leave it mostly in place as it is.> > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at zytor.com > Unsubscribe or set options at: > http://www.zytor.com/mailman/listinfo/syslinux-- Carl K