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
> 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. >If you want to test whether the "help" files work, you select the relevant row and press enter. I don't know why you would press tab, ^c and then enter for this. I am very much aware of the shortcomings of syslinux.efi. If you expect syslinux.efi to behave exactly as the BIOS variant, you are going to get disappointed, as I am. It's been several years since I last tested syslinux.efi with DISPLAY files (as those that should show the "help" for Debian's boot menu), so I don't accurately remember the problems I found back then (but I do remember that there are problems).> > > > > > 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. >Yes, that's the one from boot.img. But the cfg you posted is: PATH /EFI/BOOT/SYSLINUX/EFI64/ default vesamenu.c32 label help menu label ^Help config prompt.cfg and you said that prompt.cfg does not exist (in that particular run/test). That cfg has at least 2 problems by itself (even before I start any kind of test), and that's the cfg you reported as failing when you started this new email thread, which is not the one from 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.CFG > > target > ??? 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. >I still don't get what that '^c' has to do with selecting the "Help" menu entry. I'm not denying the possibility that BIOS and UEFI variants of vesamenu could react differently to '^C'. What I'm saying is that if the basic functionality is not working (i.e. select, then press enter, show the help files), then why try to "catch" it in some misbehavior? Since ^C is supposed to "interrupt boot in progress" (whatever that means), apparently vesamenu.c32 in UEFI simply seems to hang? Maybe. With the screen resolution issues under UEFI in general, and with the "clear screen" being so poorly managed (or rather plainly mismanaged) by syslinux.efi + vesamenu.c32, I wouldn't even care to test the "^C" behavior.> > > > ### 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. >The expectations regarding syslinux.efi are, unfortunately, too high. If I would like to perform these tests by myself, it would take me much less time than writing instructions and explaining every single detail and reason for failures (such as: the boot menu should not be tested with one entry only, whether in BIOS or in UEFI mode). Moreover, years ago I already tested syslinux.efi and many of its features. I stopped doing that, because The Syslinux Project is not really actively developing anything. Additionally, there are no indications that Debian would agree to put/add/use anything related to Syslinux in UEFI. In fact, there are hints of the opposite. @Carl, even the original bug report in Debian's bug tracker that you linked to in your original email has seen no relevant reply, and ATM the info in there would only cause more confusion (because the info is simply incorrect). Considering that there are no signs of development upstream (i.e. The Syslinux Project), and there are no signs of interest from downstream in Debian (and in fact, all signs in both cases are pointing to the opposite direction), I think it would be a waste of our time to keep these attempts. If developers for Syslinux and Debian were to show any minimal (real, concrete) interest, I would gladly perform the tests and report the results myself. Regards, Ady.
On Fri, Dec 7, 2018 at 7:47 AM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > 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. > > > > > If you want to test whether the "help" files work, you select the > relevant row and press enter. I don't know why you would press tab, ^c > and then enter for this.It was another symptom I found.> > I am very much aware of the shortcomings of syslinux.efi. If you expect > syslinux.efi to behave exactly as the BIOS variant, you are going to > get disappointed, as I am.I don't care about exact. I want functional equivalence. and only the features used by the debian installer cfg files.> > It's been several years since I last tested syslinux.efi with DISPLAY > files (as those that should show the "help" for Debian's boot menu), so > I don't accurately remember the problems I found back then (but I do > remember that there are problems). > > > > > > > > > > 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. > > > Yes, that's the one from boot.img. But the cfg you posted is: > > PATH /EFI/BOOT/SYSLINUX/EFI64/ > default vesamenu.c32 > label help > menu label ^Help > config prompt.cfg > > and you said that prompt.cfg does not exist (in that particular > run/test). That cfg has at least 2 problems by itself (even before I > start any kind of test), and that's the cfg you reported as failing > when you started this new email thread, which is not the one from > boot.img.My guess is the failure is occurring before syslinux code has tried to find the file.> > > > > > > > > > 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 > > > > target > > ??? 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. > > > > I still don't get what that '^c' has to do with selecting the "Help" > menu entry. I'm not denying the possibility that BIOS and UEFI variants > of vesamenu could react differently to '^C'. What I'm saying is that if > the basic functionality is not working (i.e. select, then press enter, > show the help files), then why try to "catch" it in some misbehavior? >Hopefully my explanation above cleared that up?> Since ^C is supposed to "interrupt boot in progress" (whatever that > means), apparently vesamenu.c32 in UEFI simply seems to hang? Maybe. > With the screen resolution issues under UEFI in general, and with the > "clear screen" being so poorly managed (or rather plainly mismanaged) > by syslinux.efi + vesamenu.c32, I wouldn't even care to test the "^C" > behavior.I would think this is easier to test and narrow down the cause. If we are lucky, it is the same problem.> > > > > > > > ### 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. > > > > > The expectations regarding syslinux.efi are, unfortunately, too high. > > If I would like to perform these tests by myself, it would take me much > less time than writing instructions and explaining every single detail > and reason for failures (such as: the boot menu should not be tested > with one entry only, whether in BIOS or in UEFI mode). > > Moreover, years ago I already tested syslinux.efi and many of its > features. I stopped doing that, because The Syslinux Project is not > really actively developing anything. > > Additionally, there are no indications that Debian would agree to > put/add/use anything related to Syslinux in UEFI. In fact, there are > hints of the opposite. > > @Carl, even the original bug report in Debian's bug tracker that you > linked to in your original email has seen no relevant reply, and ATM > the info in there would only cause more confusion (because the info is > simply incorrect). > > Considering that there are no signs of development upstream (i.e. The > Syslinux Project), and there are no signs of interest from downstream > in Debian (and in fact, all signs in both cases are pointing to the > opposite direction), I think it would be a waste of our time to keep > these attempts. > > If developers for Syslinux and Debian were to show any minimal (real, > concrete) interest, I would gladly perform the tests and report the > results myself.My goal is uefi support for https://salsa.debian.org/debconf-video-team/ansible/blob/master/usbinst/syslinux.cfg I have achieved it with the recent fix and this script: https://salsa.debian.org/carlfk-guest/ansible/blob/uefiusb/usbinst/uefi/fix_hdmedia.sh Now everything I need works, but I would prefer to push my changes upstream. Which maybe I can do, and we just live with some new bugs existing in features that didn't exist before. If this is the best we can do, I'm ok with that.> > 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