We've been successfully installing Linux using pxelinux to bootstrap our Linux (CentOS) installs for many years, but we are about to take delivery of hardware that doesn't have legacy BIOS boot support for internal drives - so I'm making my first foray into the world of EFI - and can _almost_ get it all to work, but hit an issue that I'm not sure how to 'fix' ... 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 I've updated dhcpd.conf based on info from https://wiki.syslinux.org/wiki/index.php?title=PXELINUX#UEFI (and elsewhere) to select 'syslinux.efi' as the filename to use etc. However, our dhcpd.conf, when switching on the vendor-class-identifier, will set 'deny unknown-clients' if there is no match found Watching the dhcp/tftp traffic via wireshark, I see the initial DHCP Discover, Offer, Request and ACK, followed by the tftp download of syslinux.efi - and then the client sends another DHCP Discover request, gets no reply - and repeats the DHCP Discover request 3 more times and then gives up. I believe the issue is that the 2nd set of DHCP Discover requests don't include a 'vendor-class-identifier' - so our dhcpd config ignores the request? I'm guessing this 2nd set of DHCP Discover requests come from the downloaded 'syslinux.efi' ? - if so, is it possible to configure syslinux.efi to send a vendor-class-identifier in its DHCP Discover request? I _can_ get it all to work fine - if I remove the 'deny unknown-clients' catch-all - but I'm reluctant to do this, unless it is the only way to get things working Has anyone got any other ideas on how I can solve this? Thanks James Pearson
> 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.0Please 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). Regards, Ady.
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 ? Thanks James Pearson
On 2019-10-01 06:08, James Pearson via Syslinux wrote:> We've been successfully installing Linux using pxelinux to bootstrap our > Linux (CentOS) installs for many years, but we are about to take > delivery of hardware that doesn't have legacy BIOS boot support for > internal drives - so I'm making my first foray into the world of EFI - > and can _almost_ get it all to work, but hit an issue that I'm not sure > how to 'fix' ... > > 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 > > I've updated dhcpd.conf based on info from > https://wiki.syslinux.org/wiki/index.php?title=PXELINUX#UEFI (and > elsewhere) to select 'syslinux.efi' as the filename to use etc. > > However, our dhcpd.conf, when switching on the vendor-class-identifier, > will set 'deny unknown-clients' if there is no match found > > Watching the dhcp/tftp traffic via wireshark, I see the initial DHCP > Discover, Offer, Request and ACK, followed by the tftp download of > syslinux.efi - and then the client sends another DHCP Discover request, > gets no reply - and repeats the DHCP Discover request 3 more times and > then gives up. > > I believe the issue is that the 2nd set of DHCP Discover requests don't > include a 'vendor-class-identifier' - so our dhcpd config ignores the > request? > > I'm guessing this 2nd set of DHCP Discover requests come from the > downloaded 'syslinux.efi' ? - if so, is it possible to configure > syslinux.efi to send a vendor-class-identifier in its DHCP Discover > request? > > I _can_ get it all to work fine - if I remove the 'deny unknown-clients' > catch-all - but I'm reluctant to do this, unless it is the only way to > get things working > > Has anyone got any other ideas on how I can solve this? >DHCP is executed by firmware, not Syslinux, so either file a bug report with your vendor or you have to change your configuration.>From reading RFC 2131, your configuration is wrong. RFC 2131 explicitlystates the vendor class identifier is optional (table 3, page 28.) -hpa
H. Peter Anvin wrote:>> >> Watching the dhcp/tftp traffic via wireshark, I see the initial DHCP >> Discover, Offer, Request and ACK, followed by the tftp download of >> syslinux.efi - and then the client sends another DHCP Discover request, >> gets no reply - and repeats the DHCP Discover request 3 more times and >> then gives up. >> >> I believe the issue is that the 2nd set of DHCP Discover requests don't >> include a 'vendor-class-identifier' - so our dhcpd config ignores the >> request? >> ... > > DHCP is executed by firmware, not Syslinux, so either file a bug report > with your vendor or you have to change your configuration. > > From reading RFC 2131, your configuration is wrong. RFC 2131 explicitly > states the vendor class identifier is optional (table 3, page 28.)I did contact Dell about this - but never heard anything back ... and I'm not holding my breath waiting for anything to come of it :-) I've worked around this now, but I'm still puzzled as to why a Dell 3930 workstation starts a second DHCP Discover transaction after 'syslinux.efi' has been download, whereas a Dell Latitude 7480 doesn't I accept that Dell probably have different UEFI firmware for different types of hardware - which may be the reason for this different behaviour ? However, if I set up UEFI booting of grub for the (same) Dell 3930, then the file 'shim.efi' is initially downloaded followed by the file 'grubx64.efi' - but this time, without a second DHCP Discover transaction after the first downloaded file So, hence my query of, is 'syslinux.efi' doing anything that might somehow trigger (in some cases) a 2nd DHCP Discover before it attempts to download 'ldlinux.e64' ? - i.e just wondering what might be different in the way 'shim.efi' is loaded/executed that doesn't trigger this 2nd DHCP Discover? That said, I know very little of how the UEFI firmware interacts with what gets downloaded and executed (and vice versa) - so I might very well be completely off track ... but still puzzled :-) Thanks James Pearson