Gene Cumm wrote:> > On Fri, Oct 4, 2019 at 7:47 AM James Pearson via Syslinux > <syslinux at syslinux.org> wrote: >> >> Ady Ady via Syslinux wrote: >>> >>>> We're using a CentOS 6 server running its native (ISC) dhcpd (v4.1.1) >>>> and tftpd (v 0.49). I've installed syslinux.efi and ldlinux.e64 from the >>>> syslinux-6.04-pre2 distro alongside the existing pxelinux.0 >>> >>> >>> Please avoid the official binaries from Syslinux 6.04-pre2 and >>> 6.04-pre3. Additionally, the current git master head is not useful for >>> troubleshooting. >>> >>> Whether the specific version actually has any kind of influence on >>> these particular tests, I don't know (but, at any rate I would avoid >>> the aforementioned versions anyway). >>> >>> Please try either official binaries from 6.04-pre1, or from current >>> Debian Testing. >>> >>> Please avoid mixing Syslinux-related files from different >>> versions/builds (within the same platform). >> >> I tried with 6.04-pre1 - it made no difference, the same issue as with >> 6.04-pre2 >> >> I had a look through the syslinux code, but I couldn't work out if >> syslinux.efi is responsible for the 2nd DHCP Discover I see via tcpdump >> (I can't pretend to understand the code, so I might not be looking in >> the right place) >> >> i.e. is it syslinux.efi that tries a DHCP transaction between >> downloading syslinux.efi and downloading ldlinux.e64 - or is this done >> by the host's EFI PXE firmware ? > > Since I don't recall ever seeing this kind of behavior, it makes me > think it's system-specific while SYSLINUX initializes the interfaces. > I assume you get no output on the screen?The hardware I'm using is a Dell 3930 rack mount workstation - but as this is the first time I've tried EFI PXE booting, I'm not sure what to expect ... I get on the screen: Getting cached packet MY IP is 10.64.79.186 core_udp_sendto: stalling on configure with no mapping core_udp_sendto: aborting on no mapping disable UseDefaultAddress core_udp_sendto: udp->Configure() unsuccessful (20) I believe the above errors are from the TFTP client in syslinux.efi complaining - which is probably because the 2nd DHCP transaction fails ? However, I have just tested the exact same boot procedure using a Dell laptop (Latitude 7480) - and it all worked without a problem - that is, syslinux.efi and ldlinux.e64 were downloaded without a problem - and from a tcpdump, there was *no* DHCP transaction between downloading syslinux.efi and ldlinux.e64 So I'm puzzled as to why it doesn't work on the Dell 3930 - may be a firmware bug/feature (it is running the latest firmware) ? Thanks James Pearson
> However, I have just tested the exact same boot procedure using a Dell > laptop (Latitude 7480) - and it all worked without a problem - that is, > syslinux.efi and ldlinux.e64 were downloaded without a problem - and > from a tcpdump, there was *no* DHCP transaction between downloading > syslinux.efi and ldlinux.e64 > > So I'm puzzled as to why it doesn't work on the Dell 3930 - may be a > firmware bug/feature (it is running the latest firmware) ?Reminder: syslinux.efi 6.04-pre1 does not support Secure Boot. Secure Boot needs to be set "off". Please also note that the behavior of this Dell 3930 system might vary, depending on the firmware's options; see below.>From the manual for the Dell 3930 system:Network adapter: Integrated Intel 10/100/1000 Mb/s Ethernet (RJ45) Integrated Aquantia 10 GB/s Ethernet (RJ45) Integrated NIC: Allows you to control the onboard LAN controller. The option ?Enable UEFI Network Stack? is not selected by default. The options are: * Disabled * Enabled * Enabled w/PXE (default) Integrated NIC2: Allows you to control the onboard LAN controller. The option ?Enable UEFI Network Stack? is not selected by default. The options are: * Disabled * Enabled (default) * Enabled w/PXE UEFI Network Stack Allows pre-OS and early OS networking features to use any enabled NICs. This may be used without PXE turned on. * Enable UEFI Network Stack * Default - (Disabled) So, maybe these "BIOS" options (among others) might need to be changed for syslinux.efi to work correctly with this system/NIC(s). Perhaps a PXE boot in CSM mode, using pxelinux.0 + ldlinux.c32 from the same 6.04-pre1 version would show a different behavior in this same system. Regards, Ady.
Ady Ady via Syslinux wrote:> >> However, I have just tested the exact same boot procedure using a Dell >> laptop (Latitude 7480) - and it all worked without a problem - that is, >> syslinux.efi and ldlinux.e64 were downloaded without a problem - and >> from a tcpdump, there was *no* DHCP transaction between downloading >> syslinux.efi and ldlinux.e64 >> >> So I'm puzzled as to why it doesn't work on the Dell 3930 - may be a >> firmware bug/feature (it is running the latest firmware) ? > > > Reminder: syslinux.efi 6.04-pre1 does not support Secure Boot. Secure > Boot needs to be set "off".Secure boot is off> Please also note that the behavior of this Dell 3930 system might vary, > depending on the firmware's options; see below. > > From the manual for the Dell 3930 system: > > > Network adapter: > Integrated Intel 10/100/1000 Mb/s Ethernet (RJ45) > Integrated Aquantia 10 GB/s Ethernet (RJ45) > > > Integrated NIC: > Allows you to control the onboard LAN controller. The option ?Enable > UEFI Network Stack? is not selected by default. The options are: > * Disabled > * Enabled > * Enabled w/PXE (default) > > > Integrated NIC2: > Allows you to control the onboard LAN controller. The option ?Enable > UEFI Network Stack? is not selected by default. The options are: > * Disabled > * Enabled (default) > * Enabled w/PXE > > > UEFI Network Stack > Allows pre-OS and early OS networking features to use any enabled NICs. > This may be used without PXE turned on. > * Enable UEFI Network Stack > * Default - (Disabled) > > > So, maybe these "BIOS" options (among others) might need to be changed > for syslinux.efi to work correctly with this system/NIC(s).I've tried virtually every combination of the set up options for the NICs ... including disabling one of the NICs so the system only sees one NIC i.e. at least one NIC needs to be enabled with PXE and the UEFI Network Stack enabled But nothing improves the situation> Perhaps a PXE boot in CSM mode, using pxelinux.0 + ldlinux.c32 from the > same 6.04-pre1 version would show a different behavior in this same > system.You can set up the system to PXE boot in legacy BIOS mode (which I'm guessing is CSM mode?) - and I _can_ install CentOS 7 via pxelinux.0 etc (we're using the pxelinux.0 supplied in the syslinux RPM that comes with CentOS - which I think is v4 ?) - however, as the Dell 3930 does not support booting from internal devices in legacy BIOS mode, it is impossible to then boot the installed system :-) i.e. the reason I'm going down the EFI route Thanks James Pearson
James Pearson via Syslinux wrote:> > Gene Cumm wrote: >> >> On Fri, Oct 4, 2019 at 7:47 AM James Pearson via Syslinux >> <syslinux at syslinux.org> wrote: >>> >>> Ady Ady via Syslinux wrote: >>>> >>>>> We're using a CentOS 6 server running its native (ISC) dhcpd (v4.1.1) >>>>> and tftpd (v 0.49). I've installed syslinux.efi and ldlinux.e64 >>>>> from the >>>>> syslinux-6.04-pre2 distro alongside the existing pxelinux.0 >>>> >>>> >>>> Please avoid the official binaries from Syslinux 6.04-pre2 and >>>> 6.04-pre3. Additionally, the current git master head is not useful for >>>> troubleshooting. >>>> >>>> Whether the specific version actually has any kind of influence on >>>> these particular tests, I don't know (but, at any rate I would avoid >>>> the aforementioned versions anyway). >>>> >>>> Please try either official binaries from 6.04-pre1, or from current >>>> Debian Testing. >>>> >>>> Please avoid mixing Syslinux-related files from different >>>> versions/builds (within the same platform). >>> >>> I tried with 6.04-pre1 - it made no difference, the same issue as with >>> 6.04-pre2 >>> >>> I had a look through the syslinux code, but I couldn't work out if >>> syslinux.efi is responsible for the 2nd DHCP Discover I see via tcpdump >>> (I can't pretend to understand the code, so I might not be looking in >>> the right place) >>> >>> i.e. is it syslinux.efi that tries a DHCP transaction between >>> downloading syslinux.efi and downloading ldlinux.e64 - or is this done >>> by the host's EFI PXE firmware ? >> >> Since I don't recall ever seeing this kind of behavior, it makes me >> think it's system-specific while SYSLINUX initializes the interfaces. >> I assume you get no output on the screen? > > The hardware I'm using is a Dell 3930 rack mount workstation - but as > this is the first time I've tried EFI PXE booting, I'm not sure what to > expect ... > > I get on the screen: > > ?Getting cached packet > ?MY IP is 10.64.79.186 > ?core_udp_sendto: stalling on configure with no mapping > ?core_udp_sendto: aborting on no mapping > ?disable UseDefaultAddress > ?core_udp_sendto: udp->Configure() unsuccessful (20) > > I believe the above errors are from the TFTP client in syslinux.efi > complaining - which is probably because the 2nd DHCP transaction fails ? > > However, I have just tested the exact same boot procedure using a Dell > laptop (Latitude 7480) - and it all worked without a problem - that is, > syslinux.efi and ldlinux.e64 were downloaded without a problem - and > from a tcpdump, there was *no* DHCP transaction between downloading > syslinux.efi and ldlinux.e64I've also set up EFI PXE booting of grub - which is just a simple case of changing the initial filename to download to "shim.efi" in the DHCP config - which then downloads "grubx64.efi" - this works fine on the 3930 system - and there is no DHCP attempt between downloading "shim.efi" and "grubx64.efi" files - I don't really know what this means - except, maybe there is 'something' in the way "syslinux.efi" opens the connection to download "ldlinux.e64" that is causing the 3930 PXE EFI stack to trigger a DHCP Discover request ? (I'm just grabbing at straws here ...) Thanks James Pearson
James Pearson via Syslinux wrote:> > However, I have just tested the exact same boot procedure using a Dell > laptop (Latitude 7480) - and it all worked without a problem - that is, > syslinux.efi and ldlinux.e64 were downloaded without a problem - and > from a tcpdump, there was *no* DHCP transaction between downloading > syslinux.efi and ldlinux.e64 > > So I'm puzzled as to why it doesn't work on the Dell 3930 - may be a > firmware bug/feature (it is running the latest firmware) ?Also tested with an HP laptop (Zbook 15u G5) and this shows the _exact_ same issue as with the Dell 3930 ... so the issue is looking more and more like a problem somewhere with syslinux.efi ? Thanks James Pearson
On Fri, Oct 11, 2019 at 10:27 AM James Pearson via Syslinux <syslinux at syslinux.org> wrote:> > James Pearson via Syslinux wrote: > > > > However, I have just tested the exact same boot procedure using a Dell > > laptop (Latitude 7480) - and it all worked without a problem - that is, > > syslinux.efi and ldlinux.e64 were downloaded without a problem - and > > from a tcpdump, there was *no* DHCP transaction between downloading > > syslinux.efi and ldlinux.e64 > > > > So I'm puzzled as to why it doesn't work on the Dell 3930 - may be a > > firmware bug/feature (it is running the latest firmware) ? > > Also tested with an HP laptop (Zbook 15u G5) and this shows the _exact_ > same issue as with the Dell 3930 ... so the issue is looking more and > more like a problem somewhere with syslinux.efi ?It's a client-specific interaction that I haven't seen. My guess is the attempts to just use the default address works better on some clients but triggers this second DHCP cycle on other clients. I'm assuming whatever versions you're using are the precompiled binaries from the source/binary tarballs from kernel.org? In the packet captures, I'm guessing the UEFI firmware did DHCP, fetch syslinux.efi then very quickly thereafter started the broken DHCP cycle? -- -Gene