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

[Michael Glasgow]

Gene Cumm wrote:
> >> My test x86-64 binaries:
> >>
> >> https://sites.google.com/site/genecsyslinux/sl604p0g17-x64.tgz?attredirects=0&d=1
>
> 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.

I got some time to look at this today.  Definitely better, but I
think it's still broken for me on an Oracle X5-2 with latest bios
and ilom firmware.  I loaded official binaries for this test and
replaced the two files with your patched versions.

Here's the config file:

DEFAULT type_INSTALL_to_begin

LABEL INSTALL_ovm341
        KERNEL mboot.c32
        APPEND media/ovm34_beta/images/pxeboot/xen.gz dom0_mem=max:128G dom0_max_vcpus=20 com1=57600,8n1 console=com1 --- media/ovm34_beta/images/pxeboot/vmlinuz console=ttyS0,57600n8 ks=http://10.196.129.1/ks/ovm341_unmanaged.ks --- media/ovm34_beta/images/pxeboot/initrd.img

Console output:

>>Checking Media Presence......
>>Media Present......
 Downloading NBP file...

  Succeed to download NBP file.
Getting cached packet 
My IP is 10.196.129.123
Loading type_INSTALL_to_begin... failed: No such file or directory
boot: INSTALL_ovm341

[hangs while loading the xen kernel]

In syslog you can see it request the xen kernel, then nothing further:

Oct 11 06:08:49 oosinf01 in.tftpd[72726]: RRQ from 10.196.129.123 filename efi64/mboot.c32
Oct 11 06:08:49 oosinf01 in.tftpd[72727]: RRQ from 10.196.129.123 filename efi64/libcom32.c32
Oct 11 06:08:49 oosinf01 in.tftpd[72728]: RRQ from 10.196.129.123 filename efi64/media/ovm34_beta/images/pxeboot/xen.gz

With tcpdump you can see the pxe client suddenly stops acknowledging
tftp packets, apparently before the server is done sending the kernel:

06:08:49.645053 IP (tos 0x0, ttl 64, id 37770, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0xc464!] UDP, length 1412
06:08:49.645129 IP (tos 0x0, ttl 64, id 59240, offset 0, flags [none], proto UDP (17), length 32)
    10.196.129.123.1722 > 10.196.129.1.43197: [udp sum ok] UDP, length 4
06:08:49.645143 IP (tos 0x0, ttl 64, id 37771, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0x6e43!] UDP, length 1412
06:08:50.646315 IP (tos 0x0, ttl 64, id 37772, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0x6e43!] UDP, length 1412
06:08:52.648615 IP (tos 0x0, ttl 64, id 37773, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0x6e43!] UDP, length 1412
06:08:56.652794 IP (tos 0x0, ttl 64, id 37774, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0x6e43!] UDP, length 1412
06:09:04.660903 IP (tos 0x0, ttl 64, id 37775, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0x6e43!] UDP, length 1412
06:09:20.677014 IP (tos 0x0, ttl 64, id 37776, offset 0, flags [none], proto UDP (17), length 1440)
    10.196.129.1.43197 > 10.196.129.123.1722: [bad udp cksum 0x1da2 -> 0x6e43!] UDP, length 1412
06:09:25.689215 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.196.129.123 tell 10.196.129.1, length 28
06:09:25.707342 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.196.129.123 is-at 00:10:e0:71:eb:f4, length 46

[hangs here forever]

-- 
Michael Glasgow <glasgow at beer.net>