Investigate why Beats' PRs and merges are consistently failing with "standard_init_linux.go:219: exec user process caused: exec format error" #748
Comments
|
Checking the GCP bucket, the binaries seem different for ARM64 and AMD64: |
|
I tried to reproduce this build locally, running: LOG_LEVEL=TRACE \
BEATS_USE_CI_SNAPSHOTS=true \
ELASTIC_AGENT_VERSION="pr-24086" \
.ci/scripts/functional-test.sh "fleet" "stand_alone_agent && start-agent" "8.0.0-SNAPSHOT" "pr-24086"which will grab the artifacts from the GCP bucket. I noticed the e2e are downloading the right binary from GCP (always AMD64), BUT the I could handle this in the e2e side, simply tagging the imported image with the Another thing I've checked is that importing the two flavours for an image (ARM and AMD), i.e. the elastic-agent, there will be only one Docker image in the host:
How can we get the proper platform then? It seems that Docker-for-Mac is able to select the right platform when an image is multi-platform: https://docs.docker.com/docker-for-mac/multi-arch/. Not sure about linux. |
|
I have confirmed that, when a docker host imports/loads an image, it depends on the order it's loaded: When I import the arm64 image
Then the image is "docker.elastic.co/beats/elastic-agent:8.0.0-SNAPSHOT"
And inspecting the image it tells the architecture is arm64
Given arm64 image is already in the host
When I import the amd64 image
Then the image is "docker.elastic.co/beats/elastic-agent:8.0.0-SNAPSHOT"
And inspecting the image, it tells the architecture is amd64
And the arm64 image gets "<none>" as name and tag
Given amd64 image is already in the host
When I import the arm64 image
Then the image is "docker.elastic.co/beats/elastic-agent:8.0.0-SNAPSHOT"
And inspecting the image, it tells the architecture is arm64
And the amd64 image gets "<none>" as name and tagWhich makes me think that the docker push is overriding the first pushed image (amd64) with the last pushed image (arm64) |
This should be resolved by the docker registry when you request the Docker image, the Docker CLI should detect your architecture and send it to the registry. An option is to force the architecture |
|
there is an open issue docker/for-linux#1025 |
|
But we are using docker-compose. I think #751 would have helped here, but I still see errors on PRs, although I need to investigate more on that particular case |
|
It seems the metricbeat integrations are built in amd64 format, so we need to update the build process in Beats repo. Created an issue in Beats repo: elastic/beats#25194 |
|
I think we can close this one, as all the multiplatform support (ARM/AMD is done in #707) |
Both metricbeat and elastic-agent suites are failing for any Beats' PR or merge, and that's because the docker images used in there are failing with:
It happens to any Beat, and seems related to the runtime platform of the binary.
Build demonstrating the bug
https://beats-ci.elastic.co/blue/organizations/jenkins/e2e-tests%2Fe2e-testing-mbp/detail/master/368/pipeline
CI Logs
The following log relates to Fleet's stand-alone mode, which uses a docker image
The text was updated successfully, but these errors were encountered: