arm64 ipxe package isn't an arm64 build

Thanks for reporting this.

@paelzer, it looks like ipxe can't be treated as "Architecture: All" any longer, and that debian/control will have to have src/bin-arm64-efi and some decisions based in $(dpkg-architecture -qDEB_HOST_ARCH)==arm64.

In an arm64 groovy container I got an easy to fix Werror:

include/ipxe/uri.h:178:12: error: taking address of packed member of ‘struct uri’ may result in an unaligned pointer value [-Werror=address-of-packed-member]

for groovy source code. I believe this "fix" (arm64 support) shall be easy.

Let me know if you want me to handle, please.

@xinliang,

I have been discussing your case with other server team engineer and we would like to understand better your use case, to see how to better address this, if that sounds alright for you.

Could you let us know if you're trying to PXE boot from GRUB in a real aarch64 box or in a virtual environment ? Would you share more details on your setup ?

Thanks a lot in advance!

-rafaeldtinoco

@rafaeldtinoco

Thanks for quickly responding to the bug.
Our use case is booting real bare metal aarch64 servers from remote iSCSI volume[1]. Which uses iPXE's iSCSI boot functionality. The booting iPXE script looks as bellow:
-----
:boot_iscsi
imgfree
set username xxxxxx
set password xxxxxxxxxx
set initiator-iqn iqn.2017-05.org.openstack.node-0
sanhook --drive 0x80 iscsi:10.30.96.1::3260:1:iqn.2010-10.org.openstack:volume-4e572bca-7845-44e9-b6b5-e7e27d18d1cc || goto fail_iscsi_retry

-----

For the booting process, it will first use UEFI PXE to boot into ipxe.efi, then running the above booting script to boot from remote iSCSI volume.

For the PXE environment setup, we use xinetd + tftpd-hpa reference the pxe setup guide[2].

For test convenient, we also use qemu(with or without kvm) + pce virtio nic
, the setup script is here[3].

[1]: https://docs.openstack.org/ironic/latest/admin/boot-from-volume.html
[2]: https://docs.openstack.org/ironic/latest/install/configure-pxe.html
[3]: https://github.com/openstack/ironic/blob/master/devstack/lib/ironic#L1998

@xinliang,

Thanks a lot for this feedback.

@paelzer and I have created a task for this release cycle to "reorganize" the ipxe/grub-ipxe packages and provide the aarch64 builds. We will try to merge into Debian first, and then sync it from there.. this would fix -groovy.

Depending on how things go with groovy, we can try to create a new package grub-ipxe-aarch64 for Focal or something like it, since we need to obey rules defined by https://wiki.ubuntu.com/StableReleaseUpdates for released versions.

I'll document everything in this bug for your awareness.

The Groovy Gorilla has reached end of life, so this bug will not be fixed for that release

Rafael and I had hoped to have him do that (as matching his last update here).
But he was and will be focussing on other things, so I have to stop hoping for that.

The bug is still valid and needs to be worked on, I don't have the time for it atm sadly.
But I'll tag it to have a better chance to get seen and worked on down the road.

@xinliang - since so much time has passed, if in the meantime there were other changes to this (e.g. a different way to do this emerged or you already got builds from elsewhere) we could still learn from that and adapt. Therefore if there is anything new to share let us know.

@Christian thanks for the update. Nothing new on my side. So currently, we have to build the Arm64 iPXE binary ourselves.

Finally I found some time for this ...

Right now, we have those x86 binaries:
pkg:ipxe /usr/lib/ipxe/ipxe.efi -> /boot/ipxe.efi
pkg:grub-ipxe /boot/ipxe.efi

file /boot/ipxe.efi
#/boot/ipxe.efi: MS-DOS executable PE32+ executable (DLL) (EFI application) x86-64, for MS Windows

As suggested there are arm64 use cases and ipxe allows to be build for that.
But due to the way roms work it maybe should not become non-arch-all (there are use cases for emulation too).
Instead might better try to cross build that in the same run and provide x86 and arm64 version in the same package.

If in the build env that we already have for the rest of the build we run the suggested command (modified to match the rest of the build)
  dh_auto_build --sourcedirectory=src -- V=1 NO_WERROR=1 VERSION="1.21.1+git-20220113.fbbdc3926-0ubuntu1~jammyppa1" bin-arm64-efi/ipxe.efi
we fail, but that is ok (on x86).

We need gcc-aarch64-linux-gnu to be present and need to build with that by setting it for dh_auto_build. That gives me a much better result then:
 # file src/bin-arm64-efi/ipxe.efi
 src/bin-arm64-efi/ipxe.efi: MS-DOS executable PE32+ executable (DLL) (EFI application) Aarch64, for MS Windows

For file placement, it obviously can't be /boot/ipxe.efi as it would make x86/arm64 mutually exclusive. And I could see scenarios where a host wants to run emulated arm ipxe on nonarm systemd. In any case making it mutually exclusive seems wrong.
If we rename it we also do not need to introduce a new package, we could go "along" the existing one like.
 /boot/ipxe-arm64.efi in pkg:grub-ipxe

I've made a lot of assumptions:
- about ipxe-arm64.efi as file name being useful - is it?
- would we also need want an arm64 iso? It would not just be added to the current iso as that has an x86 boot sector. Is there a real use case to a arm64 ipxe.iso?

Those assumptions might be wrong - but before sorting out those, @xin3liang I'd ask if you could test the ipxe-arm64.efi that is built in this PPA [1] as part of pkg grub-ipxe.

If it works we can sort out the rest of the details, but if it does not work I need to go back to step #1.

[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4753/+packages

More useful filenames would be those the embeded the EFI architecute tag. For example see grub:

http://archive.ubuntu.com/ubuntu/dists/jammy/main/uefi/grub2-amd64/current/
http://ports.ubuntu.com/dists/jammy/main/uefi/grub2-arm64/current/

The amd64 one is called grubx64.efi and for arm64 it is called grubaa64.efi
Similarly there are EFI architecture tags for all other arches (riscv64, i386, etc)

I also feel like we had to fix this before, it seems like it is not the first time that we have accidentally shipped X64 EFI binaries for AA64 EFI arch.

Hi Dimitri,
thanks for the suggestion - it isn't that we deliver "x86 on arm" instead it is an arch-all package that - as of today - only has builds for x86. So while it is a slight difference we "deliver x86 everywhere as intended" and the request is to also deliver arm64.

On the ISO (also x86 only atm) it is already following the efi specs and there it is
  "::efi/boot/bootx64.efi"

Debian is slow to follow on ipxe updates even when suggesting PRs doing the work in the past.
Due to that there might be dependencies for the current filename for quite a while.
But we could switch to the format you suggested while keeping a compat link on the old name to the new one.

Once @xinliang had a chance to test that PPA-build I might want/need to check if we could indeed build this for even more supported architectures (need to check what ipxe upstream claims to support). Then I could enable all those and follow the suggested naming pattern.

Note: There is only x86 and arm support (and 32 bit versions of that) in ipxe, no need to plan for "more" architectures right now.

This bug was fixed in the package ipxe - 1.21.1+git-20220113.fbbdc3926-0ubuntu1

---------------
ipxe (1.21.1+git-20220113.fbbdc3926-0ubuntu1) jammy; urgency=medium

  * Bump code to 1.21.1+git-20220113.fbbdc3926
  * d/grub-ipxe.install, d/control, d/rules: Build ipxe-arm64.efi
    (LP: #1890230)

 -- Christian Ehrhardt <email address hidden> Thu, 13 Jan 2022 14:53:40 +0100

I have provided what I think will resolve your issue, since it is optional and not hurting anybody else this is fine.
But without further engagement and verification of that I can not consider backports to e.g. focal right now.