[syslinux] UEFI: Failed to load ldlinux.e64/ldlinux.e32

Fri Oct 9 03:27:38 PDT 2015

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? - yes

Interesting.  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 snapshot

Summary: 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