Tekton Buildah on BuildPlatform linux/amd64 building with --arch=ppc64le exits with process exited with error: fork/exec /bin/sh: exec format errorsubprocess exited with status 1 #3773
Replies: 13 comments
-
|
As extra info, I was not able to build the image on my x86 based laptop, straight via podman or buildah: podman build --arch=ppc64le -t pnst-on-ppc . Is my understanding of the use case correct? |
Beta Was this translation helpful? Give feedback.
-
|
@nalind PTAL |
Beta Was this translation helpful? Give feedback.
-
|
@kitty-catt Your interpretation of what buildah does when you use the |
Beta Was this translation helpful? Give feedback.
-
|
I know that Red Hat has rejected support for qemu-user-static. So the question would be if this could be provided from EPEL. (If that would even be possible.) |
Beta Was this translation helpful? Give feedback.
-
|
Well, I've been poking at it off and on for a while, and https://github.com/nalind/fedora-qemu-user-static/blob/main/daemonset.yml seems to more or less work on my CodeReady Containers setup. I would hesitate to deploy it in a cluster that couldn't be completely destroyed and recreated as easily, though. |
Beta Was this translation helpful? Give feedback.
-
|
This morning I build my first ppc image after installing qemu-user-static. Thanks a lot, Nalin. |
Beta Was this translation helpful? Give feedback.
-
|
It turns out that I could add the package to this image via the following Dockerfile. Let me test it in the pipeline and see what happens: |
Beta Was this translation helpful? Give feedback.
-
|
I have added the package to the quay.io/buildah image and added some diagnostics: The pod that executes the Tekton Task with the qemu-user-static enhanced buildah container image still exits: I am very gratefull that I can build the application image for ppc on my intel laptop with RHEL 8.4. Does anyone have suggestions on what I could try? |
Beta Was this translation helpful? Give feedback.
-
The interpreters in the package have to be registered with the The Fedora package, for example, drops configuration files into OpenShift uses RHEL CoreOS on nodes that it provisions, and the qemu-user-static package isn't available in RHEL, so it's probably not going to become an option there. Using emulation is costly enough that I expect most installations of any size will still prefer to use native hardware. |
Beta Was this translation helpful? Give feedback.
-
|
Using oc debug node I verified "yum provides qemu-user-static" and you are 200% right, the package is not available in the coreos repos / subscription-manager. In my mind I allready had a plan to install the package on one of the nodes of the cluster, and schedule the build there via a nodeSelector. Such an approach would not be the Openshift way where the whole of CoreOS is configured at installation time, and is upgraded as a whole when a cluster gets updated. I could image that RH would support an "upgrade as a whole" configuration for the package (there is probably a lot more to it). In order for that to happen qemu-user-static would have to get into the packages for rhcos. The use case would be to allow development on low cost clusters in the cloud, and next have the build move to more expensive environments based on ppc or s390. It could make ppc/s390 contracts more attrative. The package itself is present on Fedora 35 (not RHEL 8.4) where I build the image for ppc. So, it should not be too hard to add it rhcos I believe. I can imagine the Red Hat thinks "the package will make the coreos heavy and less secure", but would not know. I could raise a support case for it with Red Hat and see what they think. Do you have considerations that I could add to the support case? |
Beta Was this translation helpful? Give feedback.
-
|
A friendly reminder that this issue had no activity for 30 days. |
Beta Was this translation helpful? Give feedback.
-
|
This feels a lot more like a discussion then an actual issue in Buildah. |
Beta Was this translation helpful? Give feedback.
-
Description
I have a Tekton Pipeline on an openshift cluster based on amd64 hardware. It builds a Dockerfile for that architecture very well. Now then, I have made a mod with the purpose of making this pipeline build the same Dockerfile into an image for the ppc64le architecture using the --arch option. The dockerfile builds from jboss-eap-7/eap73-openj9-11-runtime-openshift-rhel8 (using --from on this image that I have imported, so I can play with it). This base image has been build for ppc64le and s390x, and not for amd. The build exits with fork/exec /bin/sh: exec format errorsubprocess exited with status 1
Steps to reproduce the issue:
Describe the results you received:
The build exits as follows:
[ppc-build : build] STEP 5/21: RUN mkdir -pv /opt/eap/standalone/deployments && mkdir -pv /opt/Tivoli/monitoring/logs && mkdir -pv /data/weblogic/pnst/logs && mkdir -pv /weblogic
[ppc-build : build] process exited with error: fork/exec /bin/sh: exec format errorsubprocess exited with status 1
[ppc-build : build] error building at STEP "RUN mkdir -pv /opt/eap/standalone/deployments && mkdir -pv /opt/Tivoli/monitoring/logs && mkdir -pv /data/weblogic/pnst/logs && mkdir -pv /weblogic": exit status 1
The logs I have attached
Describe the results you expected:
I interpret the manual text for this option:
"Set the architecture of the image to be built, and that of the base image to be pulled, if the build uses one, to the provided value instead of using the architecture of the build host. (Examples: arm, arm64, 386, amd64, ppc64le, s390x)"
So, I interpret it that I specified the image to be build via the --arch option, and the image that is pulled is available for ppc64le, so it will pull it. So, it should then build the Dockerfile to ppc64le instead of the amd64 architecture of the host.
Is that a correct interpretation?
Output of
rpm -q buildahorapt list buildah:Output of
buildah version:Output of
podman versionif reporting apodman buildissue:Output of
cat /etc/*release:Output of
uname -a:Output of
cat /etc/containers/storage.conf:Beta Was this translation helpful? Give feedback.
All reactions