On Wed, Dec 12, 2018 at 4:00 PM Carl Karsten <carl at personnelware.com> wrote:> > On Tue, Dec 11, 2018 at 9:19 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > > > > > > > > > > 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? > > Everything in current BIOS mode works perfectly as far as I can tell. > We know things are different with efi, but that alone isn't a blocker. > > I don't have a efi config that is similar enough to the bios version > to be able to do any sort of 1:1 comparison. > > Creating this similar config is what I am trying to do now. details > at the end of this post. > > > > > > > > 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". > > > > I'll look at this again, but I've lost track of where it is. > syslx64debian604displayfiles? > > > > > > > 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. > > the end of the help screens show: > "Press F2 through F10 for details, or ENTER to boot:" > it doesn't bother to say: "type menu to get back to the menu." which > is what this seems to provide. > > I'd go with the simplest change, which I';m hoping is > > _ at least one of the directives is misused; or > > or, ss long as it isn't causing problems with efi, I'm happy to leave it alone. > > > > > > > > > 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. > > moving the binaries into boot/syslinux > and changing the path in /syslinux.cfg > > path /boot/syslinux > > doesn't break anything... > > target/ > ??? adgtk.cfg > ??? adspkgtk.cfg > ??? adtxt.cfg > ??? boot > ? ??? syslinux > ? ??? libcom32.c32 > ? ??? libutil.c32 > ? ??? vesamenu.c32 > ??? disk.lbl > ??? exithelp.cfg > ??? f10.txt > ??? f1.txt > ??? f2.txt > ??? f3.txt > ??? f4.txt > ??? f5.txt > ??? f6.txt > ??? f7.txt > ??? f8.txt > ??? f9.txt > ??? g2ldr > ??? g2ldr.mbr > ??? gtk.cfg > ??? initrdg.gz > ??? initrd.gz > ??? ldlinux.c32 > ??? ldlinux.sys > ??? linux > ??? menu.cfg > ??? NvVars > ??? prompt.cfg > ??? rqgtk.cfg > ??? rqspkgtk.cfg > ??? rqtxt.cfg > ??? setup.exe > ??? spkgtk.cfg > ??? splash.png > ??? stdmenu.cfg > ??? syslinux.cfg > ??? txt.cfg > ??? win32-loader.ini > > except that PATH into the bios files is a problem for efi,or is it? I just realized maybe efi can avoid that file, and so path to bios files is fine.> so I'm > trying to move syslinux.cfg > into target/boot/syslinux but I can't figure out how to do it. > > this file gives me a boot: prompt > > # target/boot/syslinux/syslinux.cfg > # path / > default /boot/syslinux/vesamenu.c32 > CONFIG ../../menu.cfg ../../ > prompt 0 > timeout 0 > > > > > > -- > Carl K-- Carl K
On Wed, Dec 12, 2018 at 4:33 PM Carl Karsten <carl at personnelware.com> wrote:> > On Wed, Dec 12, 2018 at 4:00 PM Carl Karsten <carl at personnelware.com> wrote: > > > > On Tue, Dec 11, 2018 at 9:19 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > > > > > > > > > > > > > > > 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? > > > > Everything in current BIOS mode works perfectly as far as I can tell. > > We know things are different with efi, but that alone isn't a blocker. > > > > I don't have a efi config that is similar enough to the bios version > > to be able to do any sort of 1:1 comparison. > > > > Creating this similar config is what I am trying to do now. details > > at the end of this post. > > > > > > > > > > > > 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". > > > > > > > I'll look at this again, but I've lost track of where it is. > > syslx64debian604displayfiles? > > > > > > > > > > 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. > > > > the end of the help screens show: > > "Press F2 through F10 for details, or ENTER to boot:" > > it doesn't bother to say: "type menu to get back to the menu." which > > is what this seems to provide. > > > > I'd go with the simplest change, which I';m hoping is > > > _ at least one of the directives is misused; or > > > > or, ss long as it isn't causing problems with efi, I'm happy to leave it alone. > > > > > > > > > > > > > > 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. > > > > moving the binaries into boot/syslinux > > and changing the path in /syslinux.cfg > > > > path /boot/syslinux > > > > doesn't break anything... > > > > target/ > > ??? adgtk.cfg > > ??? adspkgtk.cfg > > ??? adtxt.cfg > > ??? boot > > ? ??? syslinux > > ? ??? libcom32.c32 > > ? ??? libutil.c32 > > ? ??? vesamenu.c32 > > ??? disk.lbl > > ??? exithelp.cfg > > ??? f10.txt > > ??? f1.txt > > ??? f2.txt > > ??? f3.txt > > ??? f4.txt > > ??? f5.txt > > ??? f6.txt > > ??? f7.txt > > ??? f8.txt > > ??? f9.txt > > ??? g2ldr > > ??? g2ldr.mbr > > ??? gtk.cfg > > ??? initrdg.gz > > ??? initrd.gz > > ??? ldlinux.c32 > > ??? ldlinux.sys > > ??? linux > > ??? menu.cfg > > ??? NvVars > > ??? prompt.cfg > > ??? rqgtk.cfg > > ??? rqspkgtk.cfg > > ??? rqtxt.cfg > > ??? setup.exe > > ??? spkgtk.cfg > > ??? splash.png > > ??? stdmenu.cfg > > ??? syslinux.cfg > > ??? txt.cfg > > ??? win32-loader.ini > > > > except that PATH into the bios files is a problem for efi, > > or is it? > > I just realized maybe efi can avoid that file, and so path to bios > files is fine.for bios: # target/syslinux.cfg path boot/syslinux include menu.cfg default vesamenu.c32 prompt 0 timeout 0 trying to make an equivalent efi boot: # target/EFI/BOOT/syslinux.cfg path /EFI/BOOT/SYSLINUX/EFI64 default menu.c32 CONFIG ../../menu.cfg ../../ prompt 0 timeout 0 result: Initial menu has no LABEL entries! boot: (menu instead of vedamenu so that I can cut/paste text out of qemu where I am testing.) another idea: # target/EFI/BOOT/syslinux.cfg CONFIG ../../efi.cfg ../../ # CONFIG /efi.cfg / (same results) # target/efi.cfg # same as /syslinux.cfg except for path: path /EFI/BOOT/SYSLINUX/EFI64 include menu.cfg default menu.c32 prompt 0 timeout 0 No DEFAULT or UI configuration directive found! boot: I'm hoping I am on the right track but slipped up the syntax or something.> > > > so I'm > > trying to move syslinux.cfg > > into target/boot/syslinux but I can't figure out how to do it. > > > > this file gives me a boot: prompt > > > > # target/boot/syslinux/syslinux.cfg > > # path / > > default /boot/syslinux/vesamenu.c32 > > CONFIG ../../menu.cfg ../../ > > prompt 0 > > timeout 0 > > > > > > > > > > > > -- > > Carl K > > > > -- > Carl K-- Carl K
@Carl, I'll repeat what I said in my prior email: you don't have to keep looking, we already achieved what you want (considering that you are willing to "disregard" the screen problems and similar issues, at least for now, according to your own emails). In short: 1_ Re-read my email from 2018Dec05: www.syslinux.org/archives/2018-December/026247.html where I posted step-by-step instructions. 2_ Amendment to those instructions: 2.1_ In 'target/EFI/BOOT/SYSLX64.CFG', patch: - PATH SYSLINUX/EFI64/ + PATH EFI/BOOT/SYSLINUX/EFI64/ 2.2_ In 'target/EFI/BOOT/SYSLIA32.CFG' (which is part of the "optional"steps in the aforementioned email), patch: - PATH SYSLINUX/EFI32/ + PATH EFI/BOOT/SYSLINUX/EFI32/ 2.3_ In 'target/boot/syslinux/syslinux.cfg', patch: - PATH ./ + PATH BOOT/SYSLINUX/ 3_ There are additional potential improvements and corrections (I mean in addition to the instructions + amendment), and there are alternative ways too. Since the instructions (in the email I linked-to above) start by: "Starting from an _original_ (so-called "hd-media") boot.img..." then it should be relatively simple to get a diff/patch to send to Debian, I would guess. Unless there are complaints or disagreements or different opinions in Debian as to how to get this done, your original goal has been achieved (with the caveats I already mentioned in this same email). Regards, Ady.