The error basically means "Not a ARM64 image", which is indeed correct.

We do not support arm64 and also don't build images for it.
That goes for any helm chart and any image we release.
We also do not plan to have arm64 images in the near future.

This has been a carefull choice, because a lot of up-stream containers do not support it either, so we would to either build everything ourselves or have varying support on a case-by-case basis. Both of which we definately do not have the manpower for.

In the potential case that ARM64 gains significant popularity enough that a majority of our users need it supported we might reconsider in a decade or so.

Hi,

That means that M1 macs are also unsupported which is a shame.

Our primary target audience is currently running TrueNAS SCALE, which also does not support ARM64.

Besides that we are actively working to support Native Helm on what is basically the same hardware platform (but instead running helm directly). We never intended to also increase hardware platform support by supporting Native Helm.

But, most importantly, neither to a lot of the containers used.
So we would need to seperately start documenting which Charts do and do not support ARM64, add dedicated testing AND both contributors and maintainers to do so (because I definately have no interest in maintaining it, because I simply are short on time already)

But, most importantly, neither to a lot of the containers used.

The example used for this issue is pgadmin4, which is only single-arch because of your mirror. Upstream is https://hub.docker.com/r/dpage/pgadmin4/ and supports arm64. Spot checking several others at random, it appears that a lot of your mirror is multi-arch upstream. That includes these 93 from Linuxserver, which are multi-arch for free. Even the base images you descend from are multi-arch.

This issue is the sole thing preventing arm users from using any of these containers and charts, because they cannot escape the init container even if they revert the service container to the multi-arch upstream.

Our primary target audience is currently running TrueNAS SCALE, which also does not support ARM64.

This does not show good faith to the community. You (the project) want us (everyone else, especially non-TrueNAS installations) to believe that we are safe to use and contribute to these repositories, and won't just end up working on benefiting your the commercial product for free. Saying "Too bad, we they don't support that in our commercial product" doesn't inspire confidence. (Edited)

So we would need to seperately start documenting which Charts do and do not support ARM64, add dedicated testing AND both contributors and maintainers to do so

Lovely hyperbole, but this is about the init container, not a roadmap for your whole helm/k8s project. The scope is simple: arm64 for the init container. I agree that it would be a lovely world if you had more documentation, and more support, and more charts, maintainers, unicorns, and free soda at your desk. None of that is required to build this container (and it's base) on arm64.

#10622 should dramatically lower all those maintenance efforts, helping find time for the roadmap you listed.