-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
runtime: multi-arch build via qemu fails to exec go binary #68976
Comments
I got the error when build arm64 image in amd host machine with buildx docker buildx create --use --name=baker --driver docker-container --platform=linux/amd64 --platform=linux/arm64
docker buildx build --builder baker --platform=linux/amd64 --platform=linux/arm64 -t {tag} --push . then I tried to run manually with after unzip the command, I got the same error Dockerfile example: FROM almalinux:9.4-20240530
ENV GOROOT=/usr/local/go \
GOLANG_VERSION=1.23.0 \
GOPATH=/go
ENV PATH=$GOPATH/bin:$PATH:$GOROOT/bin
RUN set -eox pipefail \
&& dnf install -y curl \
&& mkdir -p "${GOROOT}" "$GOPATH/src" "$GOPATH/bin" && chmod -R 1777 "$GOPATH" \
&& curl -sSL "https://go.dev/dl/go${GOLANG_VERSION}.linux-$(cat < /etc/arch).tar.gz" | tar -zxvC ${GOROOT} --strip-components=1 \
# && chmod a+x ${GOROOT}/bin/* \
&& go version
WORKDIR $GOPATH |
With the circleci dockerfile, I get a segfault in gcc cc1 rather than something in go directly:
|
Might this have something to do with apparmor or other host "controls"? I was able to run the multiarch build on an Ubuntu 22.04 host using Docker 24.0.7 (from Ubuntu's packages) without errors, and inside the resulting arm64 container was able to run without errors:
|
Could you run the failing command under |
cc @golang/telemetry |
CC @matloob Independent of the root cause, a failure to start the telemetry child process shouldn't prevent the go command from being used. |
Not sure if this is helpful, but I'm attaching two |
Moved to Go1.24 milestone since this need to be fixed on the main branch first (for Go 1.24), before being considered for backporting. Please use the usual process (https://go.dev/wiki/MinorReleases) to create a separate backport tracking issue in the Go1.23.1 milestone. @findleyr It's important that issues in the minor milestones are the backport kind with a CherryPickCandidate label, otherwise we might miss them in our release meeting review. Thanks. |
Thanks again @dmitshur. @gopherbot please backport this issue to 1.23: it is a regression that breaks the go command in certain environments. |
Backport issue(s) opened: #68995 (for 1.23). Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases. |
This comment was marked as duplicate.
This comment was marked as duplicate.
Change https://go.dev/cl/607595 mentions this issue: |
…ng/go#68976). We'll disable bugged `linux/arm64` and `linux/arm` Docker image builds for now to avoid the failure, and re-enable it after Golang team fixed the problem.
Instead of calling log.Fatal if the child could not be started, call log.Print. Various factors in the user's environment could cause the child to not be able to start, but that shouldn't crash the parent process (usually the go command). Change other fatals into prints with early returns when attempting to start the child. Reset the crash output file to clean up if the child process could not be started and crashmonitoring is enabled. Updates golang/go#68976 Change-Id: I42f55dc90f68f91b272a7ebf64d2a4a3b00815c7 Reviewed-on: https://go-review.googlesource.com/c/telemetry/+/607595 Commit-Queue: Michael Matloob <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Robert Findley <[email protected]>
Change https://go.dev/cl/609195 mentions this issue: |
Change https://go.dev/cl/609196 mentions this issue: |
See golang/go#68976 Signed-off-by: bwplotka <[email protected]>
See golang/go#68976 Signed-off-by: bwplotka <[email protected]>
Signed-off-by: deadprogram <[email protected]>
Signed-off-by: deadprogram <[email protected]>
Signed-off-by: deadprogram <[email protected]>
Just tried a multi-arch build with go Has https://go.dev/cl/612218 been merged? |
@samstride It was not backported to 1.23.2, it now targets 1.23.3. You can follow the bug here. No idea why but I guess we need to wait for the next release |
Change https://go.dev/cl/617417 mentions this issue: |
Apologies for that, there was confusion on the status of the backport because this issue wasn't closed when https://go.dev/cl/592078 went in. Closing now, as there are no more known issues (other than the maybe-Google-specifc #69259 (comment)). |
Inside Google we have seen issues with QEMU user mode failing to wake a parent waitid when this child exits with SYS_EXIT. This bug appears to not affect SYS_EXIT_GROUP. It is currently unclear if this is a general QEMU or specific to Google's configuration, but SYS_EXIT and SYS_EXIT_GROUP are semantically equivalent here, so we can use the latter here in case this is a general QEMU bug. For #68976. Change-Id: I34e51088c9a6b7493a060e2a719a3cc4a3d54aa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/617417 Reviewed-by: Ian Lance Taylor <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]>
Change https://go.dev/cl/617716 mentions this issue: |
…ture check clone(CLONE_PIDFD) was added in Linux 5.2 and pidfd_open was added in Linux 5.3. Thus our feature check for pidfd_open should be sufficient to ensure that clone(CLONE_PIDFD) works. Unfortuantely, some alternative Linux implementations may not follow this strict ordering. For example, QEMU 7.2 (Dec 2022) added pidfd_open, but clone(CLONE_PIDFD) was only added in QEMU 8.0 (Apr 2023). Debian bookworm provides QEMU 7.2 by default. For #68976. Fixes #69259. Change-Id: Ie3f3dc51f0cd76944871bf98690abf59f68fd7bf Reviewed-on: https://go-review.googlesource.com/c/go/+/592078 LUCI-TryBot-Result: Go LUCI <[email protected]> Reviewed-by: Cherry Mui <[email protected]> (cherry picked from commit 7a5fc9b) Reviewed-on: https://go-review.googlesource.com/c/go/+/612218
…ature check child Inside Google we have seen issues with QEMU user mode failing to wake a parent waitid when this child exits with SYS_EXIT. This bug appears to not affect SYS_EXIT_GROUP. It is currently unclear if this is a general QEMU or specific to Google's configuration, but SYS_EXIT and SYS_EXIT_GROUP are semantically equivalent here, so we can use the latter here in case this is a general QEMU bug. For #68976. For #69259. Change-Id: I34e51088c9a6b7493a060e2a719a3cc4a3d54aa0 Reviewed-on: https://go-review.googlesource.com/c/go/+/617417 Reviewed-by: Ian Lance Taylor <[email protected]> LUCI-TryBot-Result: Go LUCI <[email protected]> (cherry picked from commit 47a9935) Reviewed-on: https://go-review.googlesource.com/c/go/+/617716
As of today, arm had issue on go 1.23. The issue is known and not fixed yet: golang/go#68976 Considering we can't downgrade to go 1.22 because of the missing Partition Cookie feature, we have to disable arm for now
Go version
go version 1.23.0 linux/arm64
Output of
go env
in your module/workspace:I'm unable to provide the output of `go env` as it fails with the same telemetry fork/exec error.
What did you do?
Our automated image build process fails to perform any step that invokes the
go
binary with the following error:The Dockerfile is here, and is being built via a script that invokes
docker buildx
with multiple platforms, like:It seems that there is something inherent in the qemu arm64 environment that renders
go
unable to fork itself to complete the telemetry setup. I'm fairly confident it's something specific to the 1.23 release as 1.22.6 builds successfully using the same setup today.What did you see happen?
Failures to invoke any
go
commandWhat did you expect to see?
A successful install and configuration of go 1.23.0 in a multi-arch docker build.
The text was updated successfully, but these errors were encountered: