[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