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