[syslinux] EFI: ipxe + syslinux = Failed to read blocks: 0xC

[Patrick Masotta]

>>>
 Using VMware I built a test setup of a server with dhcp, tftp and a 
 http-server and several pxe-clients with EFI mode turned on. This setup 
 worked, albeit with the exponential-like decay of IO rate I described 
 earlier. The work-around of using HTTP works beautifully though.
<<<

""exponential-like decay of IO rate"" could you please post a link on 
your comments on this?
 

>>>
 So it was time for the next step. Migrate this setup to our automated 
 testing environment that runs under qemu-kvm. For this I had
 to use OVMF  so the nodes would boot in EFI mode (or should I say "UEFI
 mode" ?).  This setup uses ipxe roms  to boot over the network.
 
 The short story is that I never got further than syslinux proclaiming 
 "Failed to read blocks: 0xC" before even getting to the stage where it 
 tries to load ldlinux.e64. Searching for answers I found a thread on the 
 qemu-devel list discussing this problem. The user mjt (Michael Tokarev, 
 also on this list) found a branch of ipxe that contains two patches that 
 should solve this problem. See 
 http://www.syslinux.org/archives/2015-June/023582.html for more on this. 
 Those patches haven't been merged to the master branch on ipxe.org yet.

 Unfortunately whichever version of IPXE or syslinux I try, the result is 
 always:
 
     iPXE 1.0.0+ (87981) -- Open Source Network
 Boot Firmware --
     http://ipxe.org
     Features: DNS HTTP TFTP EFI Menu
 
     net0: ec:b1:d7:75:e5:24 using NII on NII-PCI02:00.0 (open)
        [Link:down, TX:0 TXE:0 RX:0 RXE:0]
        [Link status: Unknown (http://ipxe.org/1a086194)]
     Configuring (net0 ec:b1:d7:75:e5:24)...... ok
     net0: 10.X.167.253/255.255.0.0 gw 10.X.255.254
     Next server: 10.X.255.254
     Filename: efi64/syslinux-87020-debug.efi
    
 tftp://10.X.255.254/efi64/syslinux-87020-debug.efi... ok
     efi_rdwr_sectors: read 1 bytes
     Failed to read blocks: 0xC
 
 In this screenshot the iPXE version is 87981 for commit 87981bb6. The 
 syslinux version here is 87020-or for commit 8702009f plus one extra 
 printf I added, that shows me the error happens on the very first call 
 to efi_rdwr_sectors while reading one byte.
 
 This iPXE comes from git://git.kraxel.org/ipxe, but I also tried stock 
 version 1.0.0+ and 2b15ae55 and the newest ae7f22eb2  from 
 git://git.ipxe.org/ipxe.git. For syslinux I used the precompiled binary 
 from syslinux-6.03.tar.gz, the result of 'make spotless; make efi64' on 
 that tar. Furthermore I checked out the master branch from 
 git://repo.or.cz/syslinux.git which gave me the 8702009f
 commit. I also  tried 23b2707b for reasons I forgot.
 
 For OVMF I tried both
 edk2.git-ovmf-x64-0-20150716.b1120.g387e7c1.noarch 
 from https://www.kraxel.org/repos/jenkins/ and a freshly built version 
 of commit 2ad9cf37 from https://github.com/tianocore/edk2.git.
 
 But I think I can rule out any influence from either qemu or
 ovmf/tianocore/edk2 or some misconfiguration of libvirt on my behalf, 
 because while I was busy troubleshooting this, a shiny new piece of real 
 hardware arrived: a HP Proliant DL360 gen9. So I got to play with real 
 hardware!
 
 Unfortunately, the error above was actually cut and pasted from the 
 ipmi-console session to this HP...
 
 Needless to say I tried all combinations of ipxe + syslinux on this HP 
 as well, but no luck whatsoever. Always:
 
      >> Booting Embedded LOM 1
 Port 1 : HP Ethernet 1Gb 4-port 331i     Adapter - NIC (PXE IPv4)
 
      >> Booting PXE over IPv4.
        Station IP address is 10.X.167.251
 
        Server IP address is 10.X.255.254
        NBP filename is efi64/snponly.efi
        NBP filesize is 119488 Bytes
       Downloading NBP file...
 
        NBP file downloaded successfully.
     iPXE initialising devices...ok
 
 
 
     iPXE 1.0.0+ (87981) -- Open Source Network
 Boot Firmware --     http://ipxe.org
     Features: DNS HTTP TFTP EFI Menu
 
     net0: ec:b1:d7:75:e5:24 using NII on NII-PCI02:00.0 (open)
        [Link:down, TX:0 TXE:0 RX:0 RXE:0]
        [Link status: Unknown (http://ipxe.org/1a086194)]
     Configuring (net0 ec:b1:d7:75:e5:24)...... ok
     net0: 10.X.167.253/255.255.0.0 gw 10.X.255.254
     Next server: 10.X.255.254
     Filename: efi64/syslinux-87020-or.efi
    
 tftp://10.X.255.254/efi64/syslinux-87020-or.efi... ok
     efi_rdwr_sectors: read 1 bytes
     Failed to read blocks: 0xC
 
 While playing with this HP I found there is a misunderstanding worldwide 
 about the contents of dhcp option 93, but this was also discussed 
 before: http://www.syslinux.org/archives/2014-October/022684.html.
 It  looks like all open source authors correctly use the definition from 
RFC  4578 whereas most hardware vendors stick with the definition
 from the  DHCPv6 specs which has x64 and EBC the wrong way around. 
The HP is no  exception here, but this made it very easy to chainload
 syslinux after ipxe. If dhcpd receives a 0x07, it will respond with
 ipxe.efi. This will  then do a request again with the correct (0x09) architecture
 upon which dhcpd responds with syslinux.efi. 
>>>

OK I got lost.
are you saying you finally were able to chainload syslinux.efi on the HP??
by doing what?

Best,
Patrick