ARM64 support for non-embedded systems?

[jtcressy]

Several public cloud providers are providing ARM64 architecture instances (often at reduced cost or better performance per unit of currency) such as:

• AWS - EC2 Graviton Instances
• Google Cloud / Oracle Cloud - Ampere Altra CPU's

Additionally, and less common, would be Apple's M1/M2 chips on top of which you can run virtualized ARM64 QEMU VM's

Kairos currently publishes builds for embedded ARM64 systems such as Raspberry Pi, but these builds cannot be consumed by the above ARM64 system types.

The above system types behave just like other x86_64/AMD64 cloud instances with full ACPI firmware, so we would continue to build these images the same way except the CPU arch is changed to ARM64. I've experimented with this kind of stuff on my own elemental derivative that I build for learning purposes (https://github.com/jtcressy-home/edge-images) and I am able to generate ARM iso images that can install on cloud VM's or even local QEMU VM's on my M1 macbook.

I have ran into some challenges, however, with container images during upgrades. The version of elemental I was using (which may or may not be kairos's fork - I have to go back and check) does NOT support selecting container images from a multi-arch manifest. I can build my derivative's container image for both architectures using docker buildx and upload both of them with the same tag to create a multi-arch image manifest. As far as I know, nearly every container runtime supports multi-arch manifests, be it podman, docker, containerd, etc.

This discussion could've been a FR issue, but I feel like this kind of ARM64 support may be a bit of a can of worms and I would love to see the perspective of the Kairos maintainers and contributors before setting up a full fledged issue ticket.

[mudler]

Hey @jtcressy ! Thanks for your input, that's a fair question.

I see your point, and indeed I'm not against it, I think it would be just as you suggest - a can of worm - to maintain. However, we can groom it and see what this would lead us to, I think we can at least have support for one dedicated flavor to it to reduce the maintenance cycles and see if we can make it scale.

Re: multi-arch, we are aware - that is something that didn't popped up to now as flavors are quite different from each other (even when it comes to arches) and it is quite hard to get the same Dockerfile build across all arches without having significant differences between them. That is an area we are currently exploring - reduce as much as possible the changes in between to get there first.

I'd suggest to create issues, so we can discuss and groom them - It is a community-driven project, so I'm happy to help to get this in if there is interest in also picking up and helping around it.