Syslinux - Jul 2015 - EFI: ipxe + syslinux = Failed to read blocks: 0xC

>   Some magic in dhcpd.conf:
>
>          if option architecture-type = 00:09 {
>      filename "efi64/syslinux-87020-or.efi";
>          option pxelinux.pathprefix "http://bla/efi64/";
>          } elsif option
>   architecture-type = 00:07 {
>      filename "efi64/ipxe-git87981.efi";
>      } else {
>      filename "pxelinux.0";
>      }
> <<<
>
> I "think" in this case ipxe.efi probably "did not"
chainload to pxelinux.efi
>
> When your HP booted arch=07 retrieved ipxe.efi
> ipxe.efi performs a new pxe "session" declaring arch=09
> but at the end it is the FW which loads and run now syslinux.efi.
Is this possible? Are you saying the FW is stealing the DHCP response 
away before iPXE gets it?  I haven't thought of this possibility.

Or am I misunderstanding you?

Since I'm having a hard time getting the FW to grok syslinux, I find it 
surprising it gets this far. And I also have the same problem on my 
virtual qemu/kvm/virtlib/ovmf setup where iPXE *IS* the firmware.

> it looks like iPXE might still have the chainloading issue
Which issue are you referring to?

>>> 
 Is this possible? Are you saying the FW is stealing the DHCP response 
 away before iPXE gets it?? I haven't thought of this possibility.
 
 Or am I misunderstanding you?
<<<

I'm saying that "probably" iPXE is trigerring a new PXE sequence
with a different arch but
the one that finally loads the new NBP is really the FW.
 
>>>
 Since I'm having a hard time getting the FW to grok syslinux, I find it 
 surprising it gets this far. And I also have the same problem on my 
 virtual qemu/kvm/virtlib/ovmf setup where iPXE *IS* the firmware.
<<<
I call FW to the EFI executive that comes within your PC.
iPXE is an NBP.
Your firmware should load syslinux.efi w/o much trouble,
if you do not have multi-NIC hardware. or if you use the last
patched syslinux
 
 
>>>
 > it looks like iPXE might still have the chainloading issue
 
 Which issue are you referring to?
<<<
to be able to chainload to syslinux.efi when it's iPXE the one that
makes the transfer, load and launch syslinux.efi
 
Best,
Patrick

On 31-07-15 18:45, Patrick Masotta wrote:
>>>>
>   Is this possible? Are you saying the FW is stealing the DHCP response
>   away before iPXE gets it?  I haven't thought of this possibility.
>
>   Or am I misunderstanding you?
> <<<
>
> I'm saying that "probably" iPXE is trigerring a new PXE
sequence with a different arch but
> the one that finally loads the new NBP is really the FW.
My assumtion was that PXE booting works like this:

1 - ROM FW broadcasts a DCHP request
2 - ROM Receives a reply 'filename=ipxe.efi'
3 - ROM Loads 'ipxe.efi' through tftp
4 - ROM invokes the downloaded image
5 - iPXE starts and broadcasts a DHCP request
6 - iPXE receives the reply 'filename=uri:syslinux.efi'
7 - iPXE loads syslinux.efi from supplied URI
8 - iPXE invokes the downloaded image
9 - from here on, only syslinux is running.

Of course, the FW provides the UEFI API for basic disk and network 
access and so on, but it is not a multitasking system is it? After step 
5 I did not expect the ROM FW would do anything with the DHCP responses 
to requests that were sent by iPXE.

I can set the filename to http://<ip:port>/<path>/syslinux.efi and
still
see the same result. The HP ROM FW can only do tftp, so it must be iPXE 
that's downloading and running syslinux.efi.

>>>>
>   Since I'm having a hard time getting the FW to grok syslinux, I find
it
>   surprising it gets this far. And I also have the same problem on my
>   virtual qemu/kvm/virtlib/ovmf setup where iPXE *IS* the firmware.
> <<<
> I call FW to the EFI executive that comes within your PC.
> iPXE is an NBP.
> Your firmware should load syslinux.efi w/o much trouble,
> if you do not have multi-NIC hardware. or if you use the last
> patched syslinux
I used the last patched syslinux I could find. According to the 
information on this list, the official repo is 
git://repo.or.cz/syslinux.git and the last commit over there is 8072009.

In another message Gene pointed me to another repo/branch, which I will 
try right away.

>>>>
>   > it looks like iPXE might still have the chainloading issue
>
>   Which issue are you referring to?
> <<<
> to be able to chainload to syslinux.efi when it's iPXE the one that
> makes the transfer, load and launch syslinux.efi
Is this documented somewhere? A bug, a wiki entry, a README? I would 
hate to find out i've been chasing the wrong path the past few weeks.

(On a side note, hoping not to offend anyone:)

I get the impression that UEFI and Netbooting Linux is very much in an 
Alpha state at this moment, given the amount of unofficial patches, 
knowledge buried in mailing lists and sensitive combinations of versions 
that leads to working systems. Right now I'm having flash backs to the 
early days of 1.x.y kernels with night-long compiling sessions in the 
hope of getting some piece of hardware to work.

Those were the days... ;-)