On Fri, Dec 7, 2018 at 11:16 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > If this is the best we can do, I'm ok with that. > > It's _not_ the best we can do. The question is... what exactly is this > "we"?We have both made some contributions to my little goal. you certainly share in the credit.> > After some testing (which I don't really want to keep doing myself, > because the chances that something is actually going to improve are > very close to zero... it is so disappointing / frustrating / > discouraging) I can tell you at least that when booting in UEFI mode: > > _ the 'F0' directive is broken > > _ the 'F10' directive works from CLI (aka boot prompt) but seems to > fail under (vesa)menu > > _ the screen (under the default screen resolution of syslinux.efi + > (vesa)menu.c32) is a mess and it cannot be completely clear / clean up; > IOW, [CTRL]+[L] and 'MENU CLEAR' are partially (mostly) broken > > _ the DEFAULT directive is partially broken > > _ the basic functionality of showing DISPLAY files (in this case, the > "help" files) is working; IOW the DISPLAY directive and the F1-F10 are > basically working (with the above caveats, possibly more than those), > both from CLI and from menu (no hang)I'm OK ignoring cosmetic problems. crahses/hangs I'll log bugs. I'm not too fusses over what happens after that.> > So, yes, something is indeed wrong, but when testing the basic > functionality in a simplified UEFI setup, it "works". I don't want to > be the one making up multiple tests in order to find out where exactly > the problem is when using additional features (as the multiple cfg > files in Debian use). > > Let me know whether you are curious about this. If you are, I can send > you a floppy image for you to test and repeat (replicate?) the test > (results?). You can then report back here in the Syslinux Mailing List. >Send them over - happy to report what I can replicate and discover.> 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
On Sat, Dec 8, 2018 at 12:08 AM Carl Karsten <carl at personnelware.com> wrote:> > On Fri, Dec 7, 2018 at 11:16 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > > > > > If this is the best we can do, I'm ok with that. > > > > It's _not_ the best we can do. The question is... what exactly is this > > "we"? > > We have both made some contributions to my little goal. you certainly > share in the credit. > > > > > After some testing (which I don't really want to keep doing myself, > > because the chances that something is actually going to improve are > > very close to zero... it is so disappointing / frustrating / > > discouraging) I can tell you at least that when booting in UEFI mode: > > > > _ the 'F0' directive is brokenWhat is F0? or how do I test it?> > > > _ the 'F10' directive works from CLI (aka boot prompt) but seems to > > fail under (vesa)menuworks for me in all 3 cases cli and (vesa)menu.> > > > _ the screen (under the default screen resolution of syslinux.efi + > > (vesa)menu.c32) is a mess and it cannot be completely clear / clean up; > > IOW, [CTRL]+[L] and 'MENU CLEAR' are partially (mostly) broken > >I see that too. which makes it hard to test as I often think the box has hung, but really it is just waiting for input at a prompt I can't see. and an option that displays text (both DISPLAY and COM32 pwd.c32) don't do anything visible. so I can't tell if they ran or not.> > _ the DEFAULT directive is partially broken > >What part is broken?> > _ the basic functionality of showing DISPLAY files (in this case, the > > "help" files) is working; IOW the DISPLAY directive and the F1-F10 are > > basically working (with the above caveats, possibly more than those), > > both from CLI and from menu (no hang)confirmed.> > I'm OK ignoring cosmetic problems. > crahses/hangs I'll log bugs. I'm not too fusses over what happens after that. > > > > > > So, yes, something is indeed wrong, but when testing the basic > > functionality in a simplified UEFI setup, it "works". I don't want to > > be the one making up multiple tests in order to find out where exactly > > the problem is when using additional features (as the multiple cfg > > files in Debian use).may have found another debian patch bug: ################### *** syslx64.cfg *** ################### boot: hdtl Undef symbol FAIL: exp Failed to load libgpl.c32 Failed to load COM32 file hdt.c32 boot:> > > > Let me know whether you are curious about this. If you are, I can send > > you a floppy image for you to test and repeat (replicate?) the test > > (results?). You can then report back here in the Syslinux Mailing List. > > > > Send them over - happy to report what I can replicate and discover. >I moved all the cfg and txt files into / and it seems to work the same (same things work and don't work) although given the cumbersome testing, and lack of a documented test plan, it's a little hard to know for sure. I'll say it works good enough that i'm optimistic about getting hd-media efi patch accepted. I was surprised that SYSLX64.CFG was found when it was in / and no cfg in EFI/BOOT target/ ??? EFI ? ??? BOOT ? ??? BOOTX64.EFI ? ??? cat.c32 ? ??? config.c32 ? ??? hdt.c32 ? ??? LDLINUX.E64 ? ??? libcom32.c32 ? ??? libgpl.c32 ? ??? liblua.c32 ? ??? libmenu.c32 ? ??? libutil.c32 ? ??? linux.c32 ? ??? ls.c32 ? ??? menu.c32 ? ??? pwd.c32 ? ??? rosh.c32 ? ??? vesamenu.c32 ??? f10.txt ??? f1.txt ??? f2.txt ??? f3.txt ??? f4.txt ??? f5.txt ??? f6.txt ??? f7.txt ??? f8.txt ??? f9.txt ??? NvVars ??? SYSLX64.CFG> > > 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-- Carl Kthe
> What is F0?See "prompt.cfg" in Debian's "hd-image"'s boot.img.> or how do I test it?That's an old directive that was "replaced" by the equivalent 'F10' directive (so you test it in the same exact way). BTW, in other distribution media such as Debian's ISO images, it is already changed from "f0 f10.txt" to "f10 f10.txt". This should be sent to Debian as a patch (among others).> > > _ the screen (under the default screen resolution of syslinux.efi + > > > (vesa)menu.c32) is a mess and it cannot be completely clear / clean up; > > > IOW, [CTRL]+[L] and 'MENU CLEAR' are partially (mostly) broken > > > > > I see that too. > > which makes it hard to test as I often think the box has hung, but > really it is just waiting for input at a prompt I can't see. > and an option that displays text (both DISPLAY and COM32 pwd.c32) > don't do anything visible. so I can't tell if they ran or not.You should be able to see the effects of the DISPLAY directive when testing the floppy image I sent you, because it starts with the boot prompt, not with a menu. You could also see the result of pwd.c32 by executing it from CLI first (before going into the menu). For testing purposes, and starting from the cfg file I sent you in the floppy image, you could also add between 20 and 28 "blank" lines (at least when using the default screen resolution) to the end of SYSLX64.CFG. Now imagine you have the screen full of garbage. When using this cfg file, press [ESC] twice, then '[CTRL]+[L]' and then ("blindly") type in the command 'catl' (which is equivalent to 'cat.c32 SYSLX64.CFG' in the cfg I sent you). The content of the cfg file should be displayed on screen, and since the last 20+ lines are now "blank", the effect should be and "almost-clean" screen with a boot prompt. The next command you type in should be shown more clearly now, and its result too. This is of course just a workaround for this garbage screen; OTOH it makes the use of 'cat.c32 SYSLX64.CFG' more uncomfortable and less useful in its original purpose (which was to give some clue of the content of the cfg file while troubleshooting).>From the above points regarding the garbage screen, an alternativewould be to have a "blank.cfg": SAY *** This file has 70 lines of blank lines. *** SAY *** The following lines are either *** SAY *** 70 [enter]s, or, *** SAY *** 80 space characters per line x 70 [enter]s.) *** instead of having them at the end of SYSLX64.CFG. Using 'cat.c32 blank.cfg' should be a potential "dirty" workaround that might help during testing. Of course, having this command as a menu entry in the boot menu during troubleshooting is also a possiblity.> > > _ the DEFAULT directive is partially broken > > > > > What part is broken?I'm not completely sure about the exact (incorrect) behavior. After executing vesamenu.c32 (not from the UI directive and not from the DEFAULT directive) and then [esc]aping the menu (so we are back in the boot prompt), by pressing [enter] in the boot prompt I would expect for the DEFAULT label to be executed, always; instead I am seeing that I am back into vesamenu.c32. This strange behavior requires further testing, using menu.c32 too, the CLI and several combinations of cfg files and labels with diverse sorting. Considering the lack of development activity, I have no plans on testing this problem with the DEFAULT directive any time soon.> > > both from CLI and from menu (no hang) > > confirmed.Which means that the problem you reported about "prompt.cfg" (which is supposed to trigger the help screens in Debian) is not that the help screens don't work. The feature (i.e. so-called message files, together with the DISPLAY and F1-12 directives) is basically working, but something else seems to be wrong when you choose the "help" entry in Debian's menu in UEFI mode. This issue requires more testing in order to identify what exactly is wrong in Debian's boot menu. As I mentioned before, ATM I am not willing to do all the testing and reports for Debian, especially when there is no indication that either upstream nor downstream developers care (with very few exceptions, too-few). BTW, Debian's prompt.cfg has one line INCLUDEing another cfg file, 'exithelp.cfg'. Although I mentioned this "exithelp.cfg" file in my "15 steps" in a previous email, I did not mention that this 'exithelp.cfg' file is incorrect, because I didn't want to add complexity to the instructions (and considering that your intention was/is to send a patch to Debian). (This is not news to me; I've known about this incorrect cfg file for years, but Debian's bureaucracy and lack of useful reactions from my prior attempts to actually achieve some (additional) improvements took my patience over my limit.)> may have found another debian patch bug: > > ################### > *** syslx64.cfg *** > ################### > > boot: hdtl > Undef symbol FAIL: exp > Failed to load libgpl.c32 > Failed to load COM32 file hdt.c32 > boot:I'm not sure this is a problem with Debian's package; it is more probable that the problem is in upstream's HDT code. I do know that HDT has several "BIOSisms". If it is even possible to run hdt.c32 in UEFI mode at all, then perhaps some developer might be capable of solving this particular hang. Everyone is free to wish and hope.> I was surprised that SYSLX64.CFG was found when it was in / and no cfg > in EFI/BOOTThe _cfg_ file should be searched-for and found by syslinux.efi there; no surprise really. Perhaps re-reading the whole: www.syslinux.org/wiki/index.php/Install (and/or following some links within the wiki; hint: "see also") might reduce some doubts (about that). OTOH, if the c32 modules were left under /EFI/BOOT/, and no PATH directive was used, and all the c32 modules still worked as expected anyway, then this behavior is not documented. From the point of view of the developer(s), someone might consider this to be a bug (and it probably is). Regards, Ady.