On Wed, Oct 7, 2015 at 6:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote:>> -----Original Message----- >> From: Gene Cumm [mailto:gene.cumm at gmail.com] >> Sent: Wednesday, October 07, 2015 4:43 PM >> To: For discussion of Syslinux and tftp-hpa; Geert Stappers >> Subject: Re: [syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32 >> >> On Wed, Oct 7, 2015 at 6:27 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >>> On Wed, Oct 7, 2015 at 2:33 AM, Geert Stappers <stappers at stappers.nl> wrote: >>>> On Tue, Oct 06, 2015 at 10:27:15PM -0400, Gene Cumm via Syslinux wrote: >>>>> > On Fri, Oct 2, 2015 at 4:07 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >>>>> >> >>>>> >> I have a patch that I think may help your situation of >>>>> >> syslinux.efi being unable to load ldlinux.e64/ldlinux.e32 (though >>>>> >> I don't know if any of you are using an EFI ia32 platform). >>>>> >> >>>>> >> The basics are that we try to enable UseDefaultAddress as it >>>>> >> helps certain clients with routing and works on numerous other >>>>> >> clients. If we timeout on receiving a packet and have never >>>>> >> received any packets, disable UseDefaultAddress and set the addresses manually. >>>>> >> >>>>> >> >>>>> >> git://github.com/geneC/syslinux.git >>>>> >> https://github.com/geneC/syslinux.git >>>>> >> >>>>> >> Branch 1efipxe >> >> >> https://sites.google.com/site/genecsyslinux/sl604p0g18-x64.tgz?attredirects=0&d=1 >> https://sites.google.com/site/genecsyslinux/sl604p0g18-bios.tgz?attredirects=0&d=1 >> >> Thanks Celelibi for finding that regression on DHCP options. I never expected BOOTP field siaddr to be blank yet have a booting client. >> >>>>> On Fri, Oct 2, 2015 at 4:46 PM, Derrick M <derrick.martinez at gmail.com> wrote: >>>>> > This works! Fixes my issue I have been having with the DL160s >>>>> >>>>> Further testing, preferably of the above binaries, on machines that >>>>> previously had issues loading ldlinux.e64/ldlinux.e32 would be >>>>> greatly appreciated as I know you've observed this issue and this >>>>> seems like we might have a final resolution. >>>> >>>> Please tell in your feedback >>>> if you did get a message about disabling UseDefaultAddress on the screen. >>> >>> And please try HTTP transfers too (especially DHCP option 210 set to >>> an HTTP URL). I have a feeling I need to implement some of the same >>> logic into TCP too. Reporting what you see on the screen will be >>> helpful (ie "Failed to connect: %d" where %d is a number). >> >> Ashish Shivendra, these should be better binaries for larger testing. >> >> Thank you in advance. Per-client quirks are some of the harder ones to test as often times contributors don't have machines affected by these quirks. > > > On Wed, Oct 7, 2015 at 7:58 AM, Ashish, Shivendra > <shivendra.ashish at hpe.com> wrote: >> Still getting error >> >> Disable uderdefault address > > 1) I'm presuming this is actually "disable UseDefaultAddress" > >> Core_udp_sento: udp->configure unsuccessful >> >> This message lopping in console > > Not entirely surprising (for now) though I'd expect more output than > just that and the rest of those messages would likely tell me exactly > what the return codes are. > > More importantly, you didn't mention what else you observed or any > details about your test. I thought you just said the previous binary > had initially good outlook on a DL380 G9? Details like which machines > work, which don't, and the basic layout of your PXE system would be > helpful, including: > > - Make/model of system > - UEFI firmware revision > - What NIC type and port number? > - UEFI extension agents (struggling to recall the proper term; > comparable to a BIOS PXE OROM for add-in cards) > - Was a proxyDHCP/PXE server involved in addition to DHCP?> - TFTP or HTTP transfer- TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server live relative to the client and each other (ie different subnets)?> - What precisely did you observe? On the screen? booting behavior? > - Have you performed any packet captures, preferably an tap/packet > mirror capture?> In your case, the only obvious thing is that it seems like it's TFTP transfer.-- -Gene
Ashish, Shivendra
2015-Oct-09 07:19 UTC
[syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32
Gene wrote:> On Wed, Oct 7, 2015 at 7:58 AM, Ashish, Shivendra <shivendra.ashish at hpe.com> wrote: >> Still getting error >> >> Disable uderdefault address > > 1) I'm presuming this is actually "disable UseDefaultAddress" > >> Core_udp_sento: udp->configure unsuccessful >> >> This message lopping in console > > Not entirely surprising (for now) though I'd expect more output than > just that and the rest of those messages would likely tell me exactly > what the return codes are. > > More importantly, you didn't mention what else you observed or any > details about your test. I thought you just said the previous binary > had initially good outlook on a DL380 G9? Details like which machines > work, which don't, and the basic layout of your PXE system would be > helpful, including: > > - Make/model of system > - UEFI firmware revision > - What NIC type and port number? > - UEFI extension agents (struggling to recall the proper term; > comparable to a BIOS PXE OROM for add-in cards) > - Was a proxyDHCP/PXE server involved in addition to DHCP?> - TFTP or HTTP transfer > - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server?- Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server live relative to the client and each other (ie different subnets)?> - What precisely did you observe? On the screen? booting behavior? > - Have you performed any packet captures, preferably an tap/packet > mirror capture?> In your case, the only obvious thing is that it seems like it's TFTP transfer.It seems with the binaries you had given, initrd image is not loading. It wait for some time to load initrd image and then reboots the machine. Here is the snapshot Untitled12.png attached. Here is the output from tftp server Oct 8 20:49:22 foreman in.tftpd[5383]: RRQ from 192.168.103.41 filename efi64/syslinux.efi Oct 8 20:49:22 foreman in.tftpd[5383]: tftp: client does not accept options Oct 8 20:49:22 foreman in.tftpd[5384]: RRQ from 192.168.103.41 filename efi64/syslinux.efi Oct 8 20:49:22 foreman in.tftpd[5387]: RRQ from 192.168.103.41 filename efi64/ldlinux.e64 Oct 8 20:49:22 foreman in.tftpd[5389]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/37313930-3631-5347-4834-353058385048 Oct 8 20:49:22 foreman in.tftpd[5390]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/01-38-63-bb-43-b7-d4 Oct 8 20:49:22 foreman in.tftpd[5392]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86729 Oct 8 20:49:22 foreman in.tftpd[5393]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A8672 Oct 8 20:49:22 foreman in.tftpd[5394]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A867 Oct 8 20:49:22 foreman in.tftpd[5395]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86 Oct 8 20:49:22 foreman in.tftpd[5396]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A8 Oct 8 20:49:22 foreman in.tftpd[5397]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A Oct 8 20:49:22 foreman in.tftpd[5398]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0 Oct 8 20:49:22 foreman in.tftpd[5399]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C Oct 8 20:49:22 foreman in.tftpd[5400]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default Oct 8 20:49:22 foreman in.tftpd[5401]: RRQ from 192.168.103.41 filename efi64/menu.c32 Oct 8 20:49:22 foreman in.tftpd[5401]: tftp: client does not accept options Oct 8 20:49:22 foreman in.tftpd[5402]: RRQ from 192.168.103.41 filename efi64/menu.c32 Oct 8 20:49:22 foreman in.tftpd[5403]: RRQ from 192.168.103.41 filename efi64/libutil.c32 Oct 8 20:49:22 foreman in.tftpd[5406]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default Oct 8 20:49:30 foreman in.tftpd[5573]: RRQ from 192.168.103.41 filename efi64/boot/vmlinuz0 Oct 8 20:49:36 foreman in.tftpd[5677]: RRQ from 192.168.103.41 filename efi64/boot/initrd0.img - Make/model of system - HP DL380 Gen9 server - UEFI firmware revision - P89 v1.50 (07/20/2015) - What NIC type and port number? - HP Ethernet 1Gb 4-port 331i Adapter - NIC - UEFI extension agents (struggling to recall the proper term; comparable to a BIOS PXE OROM for add-in cards) - Was a proxyDHCP/PXE server involved in addition to DHCP? - yes - TFTP or HTTP transfer - tftp - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? All on same server - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server live relative to the client and each other (ie different subnets)? Same subnet, server is 192.168.0.1 and clinet is 192.168.103.41 on 192.168.0.0/16 network - What precisely did you observe? On the screen? booting behavior? Mentioned above wit snapshot - Have you performed any packet captures, preferably an tap/packet mirror capture? Not yet, if you want I can do that. Please mention the steps. I think you need tcp dump from server at the time of client network boot ? Thanks & Regards, Ashish Shivendra
Geert Stappers
2015-Oct-09 08:36 UTC
[syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32
On Fri, Oct 09, 2015 at 07:19:37AM +0000, Ashish, Shivendra wrote:> Gene wrote: > > On Wed, Oct 7, 2015 at 7:58 AM, Ashish, Shivendra <shivendra.ashish at hpe.com> wrote: > >> Still getting error > >> > >> Disable uderdefault address > > > > 1) I'm presuming this is actually "disable UseDefaultAddress" > > > >> Core_udp_sento: udp->configure unsuccessful > >> > >> This message lopping in console > > > > Not entirely surprising (for now) though I'd expect more output than > > just that and the rest of those messages would likely tell me exactly > > what the return codes are. > > > > More importantly, you didn't mention what else you observed or any > > details about your test. I thought you just said the previous binary > > had initially good outlook on a DL380 G9? Details like which machines > > work, which don't, and the basic layout of your PXE system would be > > helpful, including: > > > > - Make/model of system > > - UEFI firmware revision > > - What NIC type and port number? > > - UEFI extension agents (struggling to recall the proper term; > > comparable to a BIOS PXE OROM for add-in cards) > > - Was a proxyDHCP/PXE server involved in addition to DHCP? > > > - TFTP or HTTP transfer > > - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? > > - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server > live relative to the client and each other (ie different subnets)? > > > - What precisely did you observe? On the screen? booting behavior? > > - Have you performed any packet captures, preferably an tap/packet > > mirror capture? > > > In your case, the only obvious thing is that it seems like it's TFTP transfer. > > > It seems with the binaries you had given, initrd image is not loading. > It wait for some time to load initrd image and then reboots the machine. > > Here is the snapshot Untitled12.png attached.This time also to the mailinglist.> Here is the output from tftp server > > Oct 8 20:49:22 foreman in.tftpd[5383]: RRQ from 192.168.103.41 filename efi64/syslinux.efi > Oct 8 20:49:22 foreman in.tftpd[5383]: tftp: client does not accept options > Oct 8 20:49:22 foreman in.tftpd[5384]: RRQ from 192.168.103.41 filename efi64/syslinux.efi > Oct 8 20:49:22 foreman in.tftpd[5387]: RRQ from 192.168.103.41 filename efi64/ldlinux.e64 > Oct 8 20:49:22 foreman in.tftpd[5389]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/37313930-3631-5347-4834-353058385048 > Oct 8 20:49:22 foreman in.tftpd[5390]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/01-38-63-bb-43-b7-d4 > Oct 8 20:49:22 foreman in.tftpd[5392]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86729 > Oct 8 20:49:22 foreman in.tftpd[5393]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A8672 > Oct 8 20:49:22 foreman in.tftpd[5394]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A867 > Oct 8 20:49:22 foreman in.tftpd[5395]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86 > Oct 8 20:49:22 foreman in.tftpd[5396]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A8 > Oct 8 20:49:22 foreman in.tftpd[5397]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A > Oct 8 20:49:22 foreman in.tftpd[5398]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0 > Oct 8 20:49:22 foreman in.tftpd[5399]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C > Oct 8 20:49:22 foreman in.tftpd[5400]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default > Oct 8 20:49:22 foreman in.tftpd[5401]: RRQ from 192.168.103.41 filename efi64/menu.c32 > Oct 8 20:49:22 foreman in.tftpd[5401]: tftp: client does not accept options > Oct 8 20:49:22 foreman in.tftpd[5402]: RRQ from 192.168.103.41 filename efi64/menu.c32 > Oct 8 20:49:22 foreman in.tftpd[5403]: RRQ from 192.168.103.41 filename efi64/libutil.c32 > Oct 8 20:49:22 foreman in.tftpd[5406]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default > Oct 8 20:49:30 foreman in.tftpd[5573]: RRQ from 192.168.103.41 filename efi64/boot/vmlinuz0 > Oct 8 20:49:36 foreman in.tftpd[5677]: RRQ from 192.168.103.41 filename efi64/boot/initrd0.img > > - Make/model of system - HP DL380 Gen9 server > - UEFI firmware revision - P89 v1.50 (07/20/2015) > - What NIC type and port number? - HP Ethernet 1Gb 4-port 331i Adapter - NIC > - UEFI extension agents (struggling to recall the proper term; comparable to a BIOS PXE OROM for add-in cards) > - Was a proxyDHCP/PXE server involved in addition to DHCP? - yes > - TFTP or HTTP transfer - tftp > - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? All on same server > - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server live relative to the client and each other (ie different subnets)? Same subnet, server is 192.168.0.1 and clinet is 192.168.103.41 on 192.168.0.0/16 network > - What precisely did you observe? On the screen? booting behavior? Mentioned above wit snapshot > - Have you performed any packet captures, preferably an tap/packet mirror capture? Not yet, if you want I can do that. Please mention the steps. I think you need tcp dump from server at the time of client network boot ? > > > Thanks & Regards, > Ashish Shivendra >-- Groeten Geert Stappers -- Leven en laten leven ------------- volgend deel ------------ Een niet-tekst bijlage is gescrubt... Naam: Untitled12.png Type: image/png Grootte: 124565 bytes Omschrijving: niet beschikbaar URL : <http://www.zytor.com/pipermail/syslinux/attachments/20151009/f2964f92/attachment-0001.png>
Geert Stappers
2015-Oct-09 09:38 UTC
[syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32, network stuff
On Fri, Oct 09, 2015 at 07:19:37AM +0000, Ashish, Shivendra via Syslinux wrote:> Gene wrote: > > > > More importantly, you didn't mention what else you observed or any > > details about your test. I thought you just said the previous binary > > had initially good outlook on a DL380 G9? Details like which machines > > work, which don't, and the basic layout of your PXE system would be > > helpful, including: > > > > - Make/model of system > > - UEFI firmware revision > > - What NIC type and port number? > > - UEFI extension agents (struggling to recall the proper term; > > comparable to a BIOS PXE OROM for add-in cards) > > - Was a proxyDHCP/PXE server involved in addition to DHCP? > > - TFTP or HTTP transfer > > - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? > > - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server liverelative to the client and each other (ie different subnets)?> > - What precisely did you observe? On the screen? booting behavior? > > - Have you performed any packet captures, preferably an tap/packet > > mirror capture? > > > > In your case, the only obvious thing is that it seems like it's TFTP transfer. > > > It seems with the binaries you had given, initrd image is not loading. > It wait for some time to load initrd image and then reboots the machine. > > Here is the snapshot Untitled12.png attached. > Here is the output from tftp server > > Oct 8 20:49:22 foreman in.tftpd[5383]: RRQ from 192.168.103.41 filename efi64/syslinux.efi > Oct 8 20:49:22 foreman in.tftpd[5383]: tftp: client does not accept options > Oct 8 20:49:22 foreman in.tftpd[5384]: RRQ from 192.168.103.41 filename efi64/syslinux.efi > Oct 8 20:49:22 foreman in.tftpd[5387]: RRQ from 192.168.103.41 filename efi64/ldlinux.e64 > Oct 8 20:49:22 foreman in.tftpd[5389]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/37313930-3631-5347-4834-353058385048 > Oct 8 20:49:22 foreman in.tftpd[5390]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/01-38-63-bb-43-b7-d4 > Oct 8 20:49:22 foreman in.tftpd[5392]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86729<snip/>> Oct 8 20:49:22 foreman in.tftpd[5399]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C > Oct 8 20:49:22 foreman in.tftpd[5400]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default > Oct 8 20:49:22 foreman in.tftpd[5401]: RRQ from 192.168.103.41 filename efi64/menu.c32 > Oct 8 20:49:22 foreman in.tftpd[5401]: tftp: client does not accept options > Oct 8 20:49:22 foreman in.tftpd[5402]: RRQ from 192.168.103.41 filename efi64/menu.c32 > Oct 8 20:49:22 foreman in.tftpd[5403]: RRQ from 192.168.103.41 filename efi64/libutil.c32 > Oct 8 20:49:22 foreman in.tftpd[5406]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default > Oct 8 20:49:30 foreman in.tftpd[5573]: RRQ from 192.168.103.41 filename efi64/boot/vmlinuz0 > Oct 8 20:49:36 foreman in.tftpd[5677]: RRQ from 192.168.103.41 filename efi64/boot/initrd0.img > > - Make/model of system - HP DL380 Gen9 server > - UEFI firmware revision - P89 v1.50 (07/20/2015) > - What NIC type and port number? - HP Ethernet 1Gb 4-port 331i Adapter - NICAnd which port of the 4 ports is used? Has the HP DL380 Gen9 also an onboard NIC?> - UEFI extension agents (struggling to recall the proper term; comparable to a BIOS PXE OROM for add-in cards) > - Was a proxyDHCP/PXE server involved in addition to DHCP? - yes > - TFTP or HTTP transfer - tftp > - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? All on same server > - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server live relative to the client and each other (ie different subnets)? Same subnet, server is 192.168.0.1 and clinet is 192.168.103.41 on 192.168.0.0/16 network > - What precisely did you observe? On the screen? booting behavior? Mentioned above wit snapshot > - Have you performed any packet captures, preferably an tap/packet mirror capture? Not yet, if you want I can do that. Please mention the steps. I think you need tcp dump from server at the time of client network boot ?That line proper formatted:> > - Have you performed any packet captures, preferably an tap/packet mirror capture? > Not yet, if you want I can do that. Please mention the steps. I think > you need tcp dump from server at the time of client network boot ?Yes, a program like tcpdump can capture network packets. On the server[1] tcpdump -i ethX -ns0 host 192.168.103.41 # to get you started with packet capturing # boot the client # see the network activity # use Control-C to stop tcpdump tcpdump -i ethx -ns0 -w sniffed00.pcap host 192.168.103.41 # boot the client # you won't see the network activity, due the write to file # use Control-C to stop tcpdump tcpdump -ns0 -r sniffed00.pcap # check content of PCAP file Send us the network capture. Groeten Geert Stappers Footnote [1] a place in the network where all (or most) of the packets of the client pass through -- Leven en laten leven
On Fri, Oct 9, 2015 at 3:19 AM, Ashish, Shivendra <shivendra.ashish at hpe.com> wrote:>>-----Original Message----- >>From: Gene Cumm [mailto:gene.cumm at gmail.com] >>Sent: Thursday, October 08, 2015 3:58 AM >>To: Ashish, Shivendra >>Cc: For discussion of Syslinux and tftp-hpa; Geert Stappers >>Subject: Re: [syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32 > >>On Wed, Oct 7, 2015 at 6:09 PM, Gene Cumm <gene.cumm at gmail.com> wrote: >>> -----Original Message----- >>> From: Gene Cumm [mailto:gene.cumm at gmail.com] >>> Sent: Wednesday, October 07, 2015 4:43 PM >>> To: For discussion of Syslinux and tftp-hpa; Geert Stappers >>> Subject: Re: [syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32 >>> >>> On Wed, Oct 7, 2015 at 6:27 AM, Gene Cumm <gene.cumm at gmail.com> wrote: >>>> On Wed, Oct 7, 2015 at 2:33 AM, Geert Stappers <stappers at stappers.nl> wrote: >>>>> On Tue, Oct 06, 2015 at 10:27:15PM -0400, Gene Cumm via Syslinux wrote: >>>>>> > On Fri, Oct 2, 2015 at 4:07 AM, Gene Cumm <gene.cumm at gmail.com> wrote:>>> https://sites.google.com/site/genecsyslinux/sl604p0g18-x64.tgz?attred >>> irects=0&d=1 >>> https://sites.google.com/site/genecsyslinux/sl604p0g18-bios.tgz?attre >>> directs=0&d=1>>>>>> Further testing, preferably of the above binaries, on machines >>>>>> that previously had issues loading ldlinux.e64/ldlinux.e32 would >>>>>> be greatly appreciated as I know you've observed this issue and >>>>>> this seems like we might have a final resolution.>> On Wed, Oct 7, 2015 at 7:58 AM, Ashish, Shivendra >> <shivendra.ashish at hpe.com> wrote: >>> Still getting error >>> >>> Disable uderdefault address >> >> 1) I'm presuming this is actually "disable UseDefaultAddress" >> >>> Core_udp_sento: udp->configure unsuccessful >>> >>> This message lopping in console >> >> Not entirely surprising (for now) though I'd expect more output than >> just that and the rest of those messages would likely tell me exactly >> what the return codes are. >> >> More importantly, you didn't mention what else you observed or any >> details about your test. I thought you just said the previous binary >> had initially good outlook on a DL380 G9? Details like which machines >> work, which don't, and the basic layout of your PXE system would be >> helpful, including:Relocating the reply.> It seems with the binaries you had given, initrd image is not loading.It loads ldlinux.e64. AWESOME! First goal on 1 machine achieved.> It wait for some time to load initrd image and then reboots the machine.Oh, the 5 minute reboot. That's disappointing.> Here is the snapshot Untitled12.png attached. > Here is the output from tftp server > > Oct 8 20:49:22 foreman in.tftpd[5383]: RRQ from 192.168.103.41 filename efi64/syslinux.efi > Oct 8 20:49:22 foreman in.tftpd[5383]: tftp: client does not accept options > Oct 8 20:49:22 foreman in.tftpd[5384]: RRQ from 192.168.103.41 filename efi64/syslinux.efi > Oct 8 20:49:22 foreman in.tftpd[5387]: RRQ from 192.168.103.41 filename efi64/ldlinux.e64 > Oct 8 20:49:22 foreman in.tftpd[5389]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/37313930-3631-5347-4834-353058385048 > Oct 8 20:49:22 foreman in.tftpd[5390]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/01-38-63-bb-43-b7-d4 > Oct 8 20:49:22 foreman in.tftpd[5392]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86729 > Oct 8 20:49:22 foreman in.tftpd[5393]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A8672 > Oct 8 20:49:22 foreman in.tftpd[5394]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A867 > Oct 8 20:49:22 foreman in.tftpd[5395]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A86 > Oct 8 20:49:22 foreman in.tftpd[5396]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A8 > Oct 8 20:49:22 foreman in.tftpd[5397]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0A > Oct 8 20:49:22 foreman in.tftpd[5398]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C0 > Oct 8 20:49:22 foreman in.tftpd[5399]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/C > Oct 8 20:49:22 foreman in.tftpd[5400]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default > Oct 8 20:49:22 foreman in.tftpd[5401]: RRQ from 192.168.103.41 filename efi64/menu.c32 > Oct 8 20:49:22 foreman in.tftpd[5401]: tftp: client does not accept options > Oct 8 20:49:22 foreman in.tftpd[5402]: RRQ from 192.168.103.41 filename efi64/menu.c32 > Oct 8 20:49:22 foreman in.tftpd[5403]: RRQ from 192.168.103.41 filename efi64/libutil.c32 > Oct 8 20:49:22 foreman in.tftpd[5406]: RRQ from 192.168.103.41 filename efi64/pxelinux.cfg/default > Oct 8 20:49:30 foreman in.tftpd[5573]: RRQ from 192.168.103.41 filename efi64/boot/vmlinuz0 > Oct 8 20:49:36 foreman in.tftpd[5677]: RRQ from 192.168.103.41 filename efi64/boot/initrd0.img > > - Make/model of system - HP DL380 Gen9 server > - UEFI firmware revision - P89 v1.50 (07/20/2015) > - What NIC type and port number? - HP Ethernet 1Gb 4-port 331i Adapter - NIC > - UEFI extension agents (struggling to recall the proper term; comparable to a BIOS PXE OROM for add-in cards) > - Was a proxyDHCP/PXE server involved in addition to DHCP? - yesInteresting. I forgot the case of the dhcpd and pxed living on the same server.> - TFTP or HTTP transfer - tftp > - TFTP/HTTP on a unique server or on the DHCP server or proxyDHCP/PXE server? All on same server > - Where do the DHCP server, proxyDHCP/PXE server, and TFTP/HTTP server live relative to the client and each other (ie different subnets)? Same subnet, server is 192.168.0.1 and clinet is 192.168.103.41 on 192.168.0.0/16 network > - What precisely did you observe? On the screen? booting behavior? Mentioned above wit snapshotSummary: Everything works without error until it attempts to load the last file and hits a 5 minute reboot timer.> - Have you performed any packet captures, preferably an tap/packet mirror capture? Not yet, if you want I can do that. Please mention the steps. I think you need tcp dump from server at the time of client network boot ?Thanks for the details. I suspect HTTP transfer of the large files should be a workaround for now. Since it's actually loading the files, a packet capture at the server should be perfectly suitable. tcpdump -i eth0 -s 0 -w mycapture.pcap host 192.168.103.41 and udp This will capture all traffic on eth0 with a maximum packet length of 65536, write it to a file mycapture.pcap, and only capture IP packets involving host 192.168.103.41 and IP protocol UDP. If you used "ether host 38:63:bb:43:b7:d4" for the capture filter, it would also show DHCP and ARP. If you then graph the network IO rate during the transfer of the last file, the graph should appear like an exponential decay. If this is true, this is the first confirmed case of the same behavior I've seen on VMware VMs. To visualize this, I've used wireshark's IO Graph (under Statistics), 1 second per tick, 1 pixel per tick and made the graph rather wide. Packets per tick and bytes per tick should both show it. -- -Gene