[syslinux] efi config hang
Carl Karsten
carl at personnelware.com
Mon Dec 10 13:07:07 PST 2018
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 broken
What is F0?
or how do I test it?
> >
> > _ the 'F10' directive works from CLI (aka boot prompt) but seems to
> > fail under (vesa)menu
works 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
More information about the Syslinux
mailing list