> 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.
On Tue, Dec 11, 2018 at 11:40 AM Ady Ady via Syslinux <syslinux at zytor.com> wrote:> > > > 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).I was all set to do this and found: authored 1 month ago by Holger Wansing - f0 ${SYSDIR}f10.txt + f10 ${SYSDIR}f10.txt https://salsa.debian.org/installer-team/debian-installer/commit/935324cb0b98f261fc2dae1a024b71bb0678ffd4> > > > > > _ 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.I see the effects, both good and bad. I'm having trouble knowing how bad the bad is.> > 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 alternative > would 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.I'm not really worried about text displaying correctly (or at all) as long as it doesn't seem to be hung.> > > > > > _ 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.I'm only interested in this case if it helps fix something I do care about. And right now I don't really have a list of what I think needs fixing. but I am getting there.> > Considering the lack of development activity, I have no plans on > testing this problem with the DEFAULT directive any time soon. >that's fine.> > > > > 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.I think so too.> > 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).Now might be a good time to fix this. I have someones ear that will likely accept simple patches.> (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.This may be something I don't care about.> > > > I was surprised that SYSLX64.CFG was found when it was in / and no cfg > > in EFI/BOOT > > > The _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).I just noticed the "or all" in this: "...any of the respective config files (or even all of them) ? namely isolinux.cfg, and/or extlinux.conf, and/or syslinux.cfg ? can optionally be located together in the same "/[[boot/]syslinux/]" directory." https://www.syslinux.org/wiki/index.php?title=Configuration_location_and_name My current plan is to put together an hd-media/boot.img that one would expect to work based on the docs. I think I need to move all the legacy binaries into boot/syslinux leave the config files in / and have a boot/syslinux/syslinux.cfg that links to /menu.cfg and see if legacy still works breaking legacy boot is a blocker.> > 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
> > > > 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. > > I see the effects, both good and bad. I'm having trouble knowing how > bad the bad is.How about comparing it with the current behaviour in BIOS mode?> I'm not really worried about text displaying correctly (or at all) as > long as it doesn't seem to be hung.This suggestion was made in order to distinguish a potential "apparent hang" vs. "it really hang". It was not really about "text clarity".> > 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). > > Now might be a good time to fix this. I have someones ear that will > likely accept simple patches.Good, because the current "exithelp.cfg" in boot.img: label menu kernel vesamenu.c32 config syslinux.cfg is incorrect, and the corresponding file for Debian's ISO images: label menu kernel vesamenu.c32 config isolinux.cfg is incorrect too. Depending on what exactly Debian actually want(ed) to achieve with this "exithelp.cfg" file, either: _ there is a need for some additional cfg file (and correct this one); or _ at least one of the directives is misused; or _ at least one of the directives should not be there. Whichever the change, it would need thorough testing of all cases / scenarios before the next freeze / release.> My current plan is to put together an hd-media/boot.img that one would > expect to work based on the docs. > I think I need to move all the legacy binaries into boot/syslinux > leave the config files in / > and have a boot/syslinux/syslinux.cfg that links to /menu.cfg > > and see if legacy still works > > breaking legacy boot is a blocker.Well, we basically already tested this concept, with the 15 steps I posted (and that you followed) in a prior email, plus the later amendment in order to workaround a known bug in the PATH directive. Regards, Ady.