ARM 64 Docker Image Builds broken since 2.6x

[goafabric]

Describe the bug

While Quarkus is sadly still missing,
support for building ARM64 Images.
This could be relatively simply fixed by suppling your own builder image, e.g.:

<quarkus.native.builder-image>goafabric/quarkus-build-aarch64:java11-21.3.0</quarkus.native.builder-image>

While this worked perfectly fine until 2.5.3,
it's now broken since 2.6x.

The build process puts out a warning that the final Image will be AMD64 and not ARM64.

Judging from another bug report here, there seems to be a change in the Base Images, Quarkus supplies.
It seems that this was multi-arch before and now seems to be solely AMD64.

The Container will of course then crash during bootstrap.

Expected behavior

Bug is fixed, to be able to use the workaround again.
Or direct support form ARM64 Images is implemented

Actual behavior

Wrong Baseimage is used, Application crashes

How to Reproduce?

No response

Output of uname -a or ver

Darwin MacBook-Air-von-Andreas.local 21.2.0 Darwin Kernel Version 21.2.0: Sun Nov 28 20:29:10 PST 2021; root:xnu-8019.61.5~1/RELEASE_ARM64_T8101 arm64

Output of java -version

openjdk version "11.0.10" 2021-01-19 LTS

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.6.2

Build tool (ie. output of mvnw --version or gradlew --version)

maven

Additional information

No response

[quarkus-bot]

/cc @geoand

[geoand]

cc @zakkak @cescoffier

[cescoffier]

I have no idea about goafabric/quarkus-build-aarch64:java11-21.3.0. Might be better to report the problem where this image is handled (it's not managed by us).

[goafabric]

@cescoffier
This builder image is handled by me, it follows the standard process of applying a custom builder image,
because quarkus does unfortunately not support ARM64 builds.
(see #17995)

But the problem is not the BUILDER Image, this works perfectly fine until 2.5.3.
But the BASEIMAGE that Quarkus applies to the final output.
It seems that this was multiarch until 2.5.x and now seems to be AMD64 only.

Also other people seemed to recognize this:
#16225 (comment)

--- dockerfile ----

FROM ghcr.io/graalvm/graalvm-ce:java11-21.3.0@sha256:d3877ce3bae9538032f02d88fb5ea5019d5686a15dd15615fb4e9c65970c72cc AS build
RUN gu install native-image
WORKDIR /project
VOLUME ["/project"]
ENTRYPOINT ["native-image"]

[goafabric]

also just found this issue for 2.7, maybe it's related ...
#22617

[cescoffier]

We had to change the base image because of the missing run-java script in the runtime images we were using. This caused several regression, and requires the users to customize the java command to tune the GC and memory limits to works well in containers.

The rollback is temporary. We are working on getting the run-java script in the runtime image, but we don't have an ETA (March/April are the target).

CC @tqvarnst @maxandersen

[cescoffier]

@goafabric I just looked at the image we currently use:

• ubi8/openjdk-17 : https://catalog.redhat.com/software/containers/ubi8/openjdk-17/618bdbf34ae3739687568813
• ubi/openjdk-11: https://catalog.redhat.com/software/containers/ubi8/openjdk-11/5dd6a4b45a13461646f677f4

I inspected their manifests and they are both multi-architectures:

• amd64
• arm64
• ppc64le
• s390x

So, it should not be a problem.

[cescoffier]

Reading other comments, it's quay.io/quarkus/quarkus-micro-image which is not multi-arch. We can (must) definitely fix this.

[goafabric]

I found a temporary workaround by reverting to the old baseimage through the maven properties
<quarkus.jib.base-native-image>registry.access.redhat.com/ubi8/ubi-minimal:8.5</quarkus.jib.base-native-image>

[cescoffier]

Yes, but you need to be aware that you use a large base image.

[Mahlatsi-andile]

@cescoffier This builder image is handled by me, it follows the standard process of applying a custom builder image, because quarkus does unfortunately not support ARM64 builds. (see #17995)

But the problem is not the BUILDER Image, this works perfectly fine until 2.5.3. But the BASEIMAGE that Quarkus applies to the final output. It seems that this was multiarch until 2.5.x and now seems to be AMD64 only.

Also other people seemed to recognize this: #16225 (comment)

--- dockerfile ----

FROM ghcr.io/graalvm/graalvm-ce:java11-21.3.0@sha256:d3877ce3bae9538032f02d88fb5ea5019d5686a15dd15615fb4e9c65970c72cc AS build RUN gu install native-image WORKDIR /project VOLUME ["/project"] ENTRYPOINT ["native-image"]

Used this graalvm-ce image and it finally worked. So glad as I spent days trying to build a native executable for linux on my M1 mac

[hamburml]

Reading other comments, it's quay.io/quarkus/quarkus-micro-image which is not multi-arch. We can (must) definitely fix this.

Any news?

[cescoffier]

Yes, the 2.0 is multi-archs.

[cescoffier]

Btw, I'm going to close this issue, as we now provide multi arch's images.