-
Notifications
You must be signed in to change notification settings - Fork 139
✨ feat: add arm64 iPXE binaries #826
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Hi @synthe102. Thanks for your PR. I'm waiting for a github.com member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/ok-to-test |
shenwei66
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi friend,please have a look my comments.
| # NOTE(elfosardo): warning should not be treated as errors by default | ||
| NO_WERROR=1 make bin/undionly.kpxe "bin-$ARCH-efi/snponly.efi" | ||
| NO_WERROR=1 make bin/undionly.kpxe bin-x86_64-efi/snponly.efi && \ | ||
| NO_WERROR=1 make CROSS=aarch64-linux-gnu- bin-arm64-efi/snponly.efi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What will happen if my server is arm? From line 26 to 27.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even without my changes, the image can't be built on arm64. bin/undionly.kpxe can only be built on amd64 servers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We discussed on Slack that adding arm64 support to amd64 image was a nice first step rather than trying to add in one shot arm64 support and multi-arch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, the assumption is that the build happen on x86
should we consider also the arm64 case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As mentioned above, currently the image can't be built for the linux/arm64 target.
Dockerfile
Outdated
| dnf install -y gcc git make xz-devel | ||
| dnf groupinstall -y 'Development Tools' && \ | ||
| dnf install -y epel-release && \ | ||
| dnf install -y gcc git make xz-devel gcc-aarch64-linux-gnu gcc-c++-aarch64-linux-gnu |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if my server is arm64, we can’t execute this command,right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes you can ! I tried during development to have a multi-arch image, and it works. Its the undionly.kpxe build that causes issue on arm64.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're giving as assumed that we're running on x86 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes as the image can't be cross compiled right now because of syslinux.
It means that:
- syslinux-nonlinux in
main-package-list.txtcan't be installed bin/undionly.kpxecan't be compiled on arm64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since both are required for legacy boot, it sort of makes sense. I guess the path forward is to install them conditionally with understanding that only UEFI can be used for ARM64 clusters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, it does not have to be in this PR since, as you said, ironic-image cannot be built on ARM64 now. But it's relatively easy to fix that, and I think we should do exactly that: only build undionly.kpxe and install syslinux for ironic-image on amd64.
|
/cc @honza |
|
/test |
|
@synthe102: The The following commands are available to trigger optional jobs: DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
/test metal3-dev-env-integration-test-centos-main |
|
/test metal3-centos-e2e-integration-test-main |
|
/test metal3-ubuntu-e2e-integration-test-main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request overview
This PR adds support for arm64 architecture in the iPXE boot process by introducing arm64-specific iPXE binaries. The changes enable arm64 clients to boot using the appropriate snponly-arm64.efi bootloader instead of the x86_64 version.
- Cross-compilation support added to build arm64 iPXE binaries alongside x86_64 binaries
- DHCP configuration updated to route arm64 clients (client-arch 11) to the arm64-specific bootloader
- Runtime script updated to deploy the new arm64 binary to the TFTP boot directory
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| Dockerfile | Adds cross-compilation toolchain for aarch64 and builds snponly-arm64.efi binary; copies the arm64 binary to the final image |
| scripts/rundnsmasq | Updates firmware copy operations to include snponly-arm64.efi in both custom and default firmware paths |
| ironic-config/dnsmasq.conf.j2 | Separates arm64 EFI clients (client-arch 11) into dedicated efi-arm64 tag with architecture-specific bootloader configuration for both IPv4 and IPv6 |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
/test metal3-centos-e2e-integration-test-main |
elfosardo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you considering only the scenario where the image is built on x86 ?
| echo "keepcache=1" >> /etc/dnf/dnf.conf && \ | ||
| dnf install -y gcc git make xz-devel | ||
| dnf groupinstall -y 'Development Tools' && \ | ||
| dnf install -y epel-release && \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what's the need for EPEL?
I would really like to see an alternative, we removed the need for the EPEL repo since a while
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EPEL is needed for gcc-aarch64-linux-gnu and gcc-c++-aarch64-linux-gnu. I'm not familiar with the RHEL ecosystem, if there is another way to grab those packages I'll be glad to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, install packages from EPEL without enabling it globally (you can enable a repo just for one command). Just so that we have control over where packages are coming from.
Dockerfile
Outdated
| dnf install -y gcc git make xz-devel | ||
| dnf groupinstall -y 'Development Tools' && \ | ||
| dnf install -y epel-release && \ | ||
| dnf install -y gcc git make xz-devel gcc-aarch64-linux-gnu gcc-c++-aarch64-linux-gnu |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're giving as assumed that we're running on x86 ?
| # NOTE(elfosardo): warning should not be treated as errors by default | ||
| NO_WERROR=1 make bin/undionly.kpxe "bin-$ARCH-efi/snponly.efi" | ||
| NO_WERROR=1 make bin/undionly.kpxe bin-x86_64-efi/snponly.efi && \ | ||
| NO_WERROR=1 make CROSS=aarch64-linux-gnu- bin-arm64-efi/snponly.efi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same here, the assumption is that the build happen on x86
should we consider also the arm64 case?
Dockerfile
Outdated
| echo "tsflags=nodocs" >> /etc/dnf/dnf.conf && \ | ||
| echo "keepcache=1" >> /etc/dnf/dnf.conf && \ | ||
| dnf install -y gcc git make xz-devel | ||
| dnf groupinstall -y 'Development Tools' && \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd prefer we specify packages instead of using a group to avoid bringing in unnecessary dependencies without realizing it.
Signed-off-by: synthe102 <[email protected]>
|
It seems there is a race condition caused Edit: fixed by setting |
Signed-off-by: synthe102 <[email protected]>
@synthe102 that was not happening before though, so what's changed? |
|
I think its a race condition where |
|
@elfosardo You're right, its a regression. Introduced by disabling epel: dnf install -y epel-release
dnf config-manager --set-disabled epel
dnf install -y gcc git make xz-devel
dnf install --enablerepo=epel -y gcc-aarch64-linux-gnu gcc-c++-aarch64-linux-gnuThis doesn't: dnf install -y epel-release
dnf install -y gcc git make xz-devel
dnf install -y gcc-aarch64-linux-gnu gcc-c++-aarch64-linux-gnu |
|
Still can't make it work with I didn't notice any difference in build time with and without |
|
/test metal3-centos-e2e-integration-test-main |
What this PR does / why we need it:
This PR adds arm64 iPXE binaries to the Ironic image and points arm64 DHCP clients to the correct file.
Linked with #502.
Checklist: