[syslinux] current state of pxelinux for UEFI...

[Ady Ady]

> On 8 Nov 2019 at 0:42, Ady Ady via Syslinux wrote:
> >
> > As usual, builds/versions should not be mixed, at least within the
> > same platform (bios/ia32/x64).
> >
> I keep versions strictly separated. Both the build directories under
> /usr/src/syslinux-<VERSION>, and under
> /tftpboot/pxelinux/<VERSION>/efi64/<my data> and I flip the "filename"
> and "pathprefix" in dhcpd.conf.
> 
>  > Currently, the Syslinux-related binary packages in Debian are:
> > 
> > _ extlinux
> > _ isolinux
> > _ pxelinux
> > _ syslinux
> > _ syslinux-common
> > _ syslinux-efi
> > _ syslinux-utils
> >
> okay thanks a lot for explaining that :-)
> So for the record at the moment: 
> I've tried the syslinux.efi from
>   syslinux-efi_6.04~git20190206.bf6db5b4+dfsg1-1_all.deb
> and ldlinux.e64 from
>   syslinux-common_6.04~git20190206.bf6db5b4+dfsg1-1_all.deb
> 
> On my hardware from AsRock (J4105) and Gigabyte (J1900) the following
> recent versions of pxelinux/syslinux: 1) debian
> 6.04~git20190206.bf6db5b4+dfsg1-1 2) vanilla git master at the moment 3)
> the sherbszt branch all behave the same, in the aforementioned way: they
> get stuck asking for ldlinux.e64, even though this has been provided at
> least once, on the first request (the path and filename was right and
> TFTP does not report a NAK). They never ask for the config file, as
> specified in the pxelinux.configfile option.
> 
> The two motherboards I've tested so far, may have common 
> denominators, in that the UEFI codebase is an AMI APTIO 64bit and the
> HW-specific lower layers of the PXE stack consist of a UEFI driver by
> Realtek (some RTL8168/8169 hardware).
> 
> For a moment I hesitated "well maybe the syslinux.efi, at the moment of
> waking up on the diskless target, doesn't get the option pointing to the
> config file"? But no, that's not the problem either.
> 
> I noticed the explanation in the PXELINUX wiki entry, that 
> "In ISC dhcp versions greater than 3.0, site-local option spaces 
> start at 224, not 128 (to be compliant with RFC 3942), so you should
> define the PXELINUX options 208-211 as regular DHCP options, rather than
> site local ones." Yes indeed, I've been using the "site-local custom
> option space" all along, so I tried applying that configuration change.
> Again I'm using 4.3.6 - and the net result in the DHCP protocol is
> exactly the same = either way works for me in dhcpd.conf: site-local or
> regular declaration of the options. After all, this same dhcpd.conf has
> been working with PXElinux 3.53 for many years.
> 
> Attached is a screenshot from wireshark (parsing a .pcap taken by 
> tcpdump running on the DHCP server) = proving that DHCP does indeed push
> all the pxelinux options as specified in dhcpd.conf.
> 
> Actually I've tested by mistake that if I *do not* specify the custom
> pxelinux options at all, syslinux.efi still starts out by asking for
> ldlinux.e64 at the correct path prefix :-)
 
 
Is the core module, "ldlinux.*", located in the same directory as the 
bootloader file? I'm asking this because Debian has been unnecessarily 
complicating this matter for years.

Is there any chance for you to test the same HW booting in 
CSM/BIOS/Legacy mode instead of UEFI (using Debian's binaries)?

Such test(s) might narrow down the problem, for example if pxelinux.0 
works correctly but syslinux.efi still fails.

Also, what happens with these suggested tests when _not_ using the 
"pxelinux.configfile" option?

What happens if the relevant binaries are all located in the root, 
instead of being located in a subdirectory?

FWIW, I'm not surprised by the reported behavior. Nor by the lack of 
participation of developers. The "real issue" is whether at some point 
some kind of code development would actually be seen.

Regards,
Ady.