Dear gentlemen,
I think I'd better start another thread for this...
thanks to Ady Ady and Gregory Lee Bartholomew for their responses to
my early question.
Just for the record, my fresh experience with PXElinux 6.x follows:
syslinux.efi version 6.03 does boot to the extent that it shows a
prompt, but if I provide it with a CFG file containing several
labels, no matter what label I type at the boot prompt, it always
loads the default label :-)
And, it then croaks about incorrect signature... and yes I do have
secure boot disabled in the BIOS. It sure won't start any .efi
exectuable that I've tried (such as ipxe.efi or memtest.efi or the
rEFInd, which OTOH is not a surprise, as this is not supposed to
work). I believe I've noticed Ady Ady's earlier message that
chain-loading further bootloaders does not work.
If I try to load a kernel and an initrd, it takes ages to load them,
and apparently syslinux then hangs once the two files get loaded,
there's never any further message.
Do I need to modify the standard kernel bzImage in any way, for it to
be UEFI-bootable via PXElinux or Grub2 ?
Next I tried the current latest GIT "master".
That doesn't even get as far as showing a prompt.
I'm attaching a log snippet from the TFTP server.
Apparently it loads the syslinux.efi, then it loads the syslinux.efi
again, then it loads the ldlinux.e64 (prepared at the path where it's
looking for it), and then tries to load that same file ldlinux.e64
again, over and over several times, as if the first load attempt
failed... I believe the PXE stack actually flashes a message that it
has loaded the boot file, but that message vanishes in a fraction of
a second and then it gets stuck with just about two text lines, as if
nothing got loaded...
Tomorrow I'll try the branch prepared by Sebastian Herbszt, mentioned
here:
https://www.syslinux.org/archives/2019-July/026484.html
I've also found Gregory's patch here:
https://www.syslinux.org/archives/2019-July/026476.html
If I understand this correctly, it doesn't fix the buggy strncat
Gregory has mentioned - the patch adds support for another boot image
format called BLS1 (now becoming popular).
There's probably no point for me to try to apply this patch...
I've also tried looking at the binaries available from Debian testing
packages "pxelinux" and "syslinux-common"... and it seems to
me that
the "pxelinux" package only contains binaries for the legacy BIOS
PXE, and the "syslinux-common" contains just the c32 modules for all
three flavours (BIOS/UEFI32/UEFI64) but no syslinux.efi...
Any response would be welcome :-)
So far I've been trying with one particular board by AsRock.
I should probably try other motherboards too, for comparison.
I have other hardware around, where a UEFI-flavoured PXE stack
is an option (besides legacy PXE) or where UEFI PXE is the only way.
I may test them later as I get the boxes or boards in my hands.
I work in a "computer hardware toy store" and I tend to use Linux for
some diagnostic tasks - hence my motivation to have a netboot
environment in the LAN.
Frank Rysanek
-------------- next part --------------
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: bug1.txt
Date: 7 Nov 2019, 22:43
Size: 1391 bytes.
Type: Text
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug1.txt
Type: application/octet-stream
Size: 1391 bytes
Desc: not available
URL:
<https://lists.syslinux.org/archives/syslinux/attachments/20191107/4f21e4a3/attachment.obj>
> Any response would be welcome :-)As usual, builds/versions should not be mixed, at least within the same platform (bios/ia32/x64). Currently, the Syslinux-related binary packages in Debian are: _ extlinux _ isolinux _ pxelinux _ syslinux _ syslinux-common _ syslinux-efi _ syslinux-utils The list of packages and their contents might (or might not) change in the future. I don't know for how long we will have to repeat the following: the current official upstream git master head is not worth testing, as it will either FTBFS or the resulting binaries will fail. Testing official upstream 6.04-pre2 or 6.04-pre3 will fail too. Unless potential regressions are part of the testing goals, there is no point in testing with official upstream 6.03 when 6.04-pre1 (or, even better, the current Debian Testing binary packages) are available. Regards, 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 :-) And yes I now understand that I'm being futile in testing these very recent upstream work-in-progress versions of syslinux-efi :-) Let me do this as a gratuitous snippet of feedback from the wild.> I don't know for how long we will have to repeat the following: the > current official upstream git master head is not worth testing, as it > will either FTBFS or the resulting binaries will fail. Testing official > upstream 6.04-pre2 or 6.04-pre3 will fail too. > > Unless potential regressions are part of the testing goals, there is no > point in testing with official upstream 6.03 when 6.04-pre1 (or, even > better, the current Debian Testing binary packages) are available.yes... apologies, I know us newbies, we can be overwhelming... Following my general intuition that if I play with bleeding edge features, I should try bleeding edge code first, before reporting bugs :-) But I don't mean to talk back, I'm happy not to be "walking in your shoes" on this... I love your patience with me :-) Frank -------------- next part -------------- The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: pxelinux-efi-dhcp.png Date: 8 Nov 2019, 9:35 Size: 70758 bytes. Type: Unknown -------------- next part -------------- A non-text attachment was scrubbed... Name: pxelinux-efi-dhcp.png Type: application/octet-stream Size: 70758 bytes Desc: not available URL: <https://lists.syslinux.org/archives/syslinux/attachments/20191108/025f9233/attachment-0001.obj>
Ady Ady via Syslinux wrote:> > As usual, builds/versions should not be mixed, at least within the same > platform (bios/ia32/x64). > > Currently, the Syslinux-related binary packages in Debian are: > > _ extlinux > _ isolinux > _ pxelinux > _ syslinux > _ syslinux-common > _ syslinux-efi > _ syslinux-utils > > The list of packages and their contents might (or might not) change in > the future. > > I don't know for how long we will have to repeat the following: the > current official upstream git master head is not worth testing, as it > will either FTBFS or the resulting binaries will fail. Testing official > upstream 6.04-pre2 or 6.04-pre3 will fail too. > > Unless potential regressions are part of the testing goals, there is no > point in testing with official upstream 6.03 when 6.04-pre1 (or, even > better, the current Debian Testing binary packages) are available.Being a happy pxelinux user for many, many years, my forced introduction to booting UEFI about a month ago was not as straight forward as it should have been (and hence my reason for subscribing to this list) It took me a while to find which release of syslinux worked with UEFI - in my case 6.04-pre2 (from https://www.zytor.com/pub/syslinux/Testing/6.04/) - this appears to work the best for me As I'm not a Debian user, it also took me a while to track down the 'Debian Testing binary packages' - but using syslinux.efi and ldlinux.e64 from these didn't work any better or worse than the 6.04-pre2 I had already got working ... May be the Syslinux UEFI Wiki page(s) need to be updated with details of which versions _actually_ work (and may be links to the working Debian downloads) ? Or even better, may be a working non-pre 6.04 release ? Thanks James Pearson
Do note that not everyone is running a Debian based system, so "the current Debian Testing binary packages" are worthless to us. On Fri, Nov 08, 2019 at 12:42:45AM +0000, Ady Ady via Syslinux wrote:> > Any response would be welcome :-) > > > As usual, builds/versions should not be mixed, at least within the same > platform (bios/ia32/x64). > > Currently, the Syslinux-related binary packages in Debian are: > > _ extlinux > _ isolinux > _ pxelinux > _ syslinux > _ syslinux-common > _ syslinux-efi > _ syslinux-utils > > The list of packages and their contents might (or might not) change in > the future. > > I don't know for how long we will have to repeat the following: the > current official upstream git master head is not worth testing, as it > will either FTBFS or the resulting binaries will fail. Testing official > upstream 6.04-pre2 or 6.04-pre3 will fail too. > > Unless potential regressions are part of the testing goals, there is no > point in testing with official upstream 6.03 when 6.04-pre1 (or, even > better, the current Debian Testing binary packages) are available. > > Regards, > Ady. > > _______________________________________________ > Syslinux mailing list > Submissions to Syslinux at syslinux.org > Unsubscribe or set options at: > https://lists.syslinux.org/syslinux-- Dr. William R. Somsky somsky at uw.edu Department of Physics, Box 351560 B217 Phys-Astro Bldg Univ. of Washington, Seattle WA 98195-1560 206-616-2954