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

[BALATON Zoltan]

Hello,

I can't help with the problems on real hardware but have come across the 
qemu problems before and maybe I can give some hints on that.

On Fri, 31 Jul 2015, Oscar Roozen via Syslinux wrote:
> 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

This is happening if you are trying to boot syslinux.efi from iPXE that 
was not patched. In my understanding iPXE patches some UEFI network 
services in order to provide a better user experience but this 
unfortunately breaks syslinux's usage of UEFI services where it thinks 
it's not booted from PXE (cannot find PxeBaseCodeProtocol) and tries to 
read from disk which fails with the above error.

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

If you go back one message in that thread you'll find a link to another 
thread explaining what's happening and what workarounds are available 
here: http://sourceforge.net/p/edk2/mailman/message/33735116/

The easiest probably is to use virtio-net with the romfile= option to 
completely disable iPXE roms and use the OVMF built in driver. You can 
tell it's using that if you don't see the iPXE header just syslinux.efi 
booting. This unfortunately only works with virtio-net as that's the only 
network inferface that OVMF has a driver. Or you could try a patched iPXE 
rom or a recent version of qemu (maybe git or latest rc releases) that 
possibly have patched iPXE roms which may work better. Using older qemu or 
original upstream iPXE probably will not work and lead to this error.

> 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

Since iPXE is involved it can be the same problem as with qemu but it's 
possible that without iPXE you find other problems caused by multiple 
network interfaces. I'm not sure about that. After you've ruled out iPXE 
maybe you could try to boot from different interfaces and see if they 
behave differently.

Regards,
BALATON Zoltan