podman: Cannot do cross-platform builds from Dockerfiles with `RUN` commands
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
I am using an arm-based Mac (M1 Ultra) to build an image for an Intel-based server. The Dockerfile has a RUN command in it. The build always fails when it reaches the RUN command.
Steps to reproduce the issue:
- Have a Dockerfile with a
RUNcommand in it. - From an M1-based Mac, build your image.
podman build --platform=linux/amd64 -t my_tag .
- Note failure at
RUNstep
STEP 6/20: RUN npm install -g npm
exec container process `/bin/sh`: Exec format error
Error: error building at STEP "RUN npm install -g npm": error while running runtime: exit status 1
Describe the results you received:
The image failed to build with an Exec format error, the same error I would expect if I deployed an arm container on an amd64 machine.
Describe the results you expected:
I should be able to build an image on my M1 machine.
Additional information you deem important (e.g. issue happens only occasionally):
This happens consistently
Output of podman version:
Client: Podman Engine
Version: 4.0.3
API Version: 4.0.3
Go Version: go1.18
Built: Fri Apr 1 10:28:59 2022
OS/Arch: darwin/arm64
Server: Podman Engine
Version: 4.0.2
API Version: 4.0.2
Go Version: go1.16.14
Built: Thu Mar 3 08:58:50 2022
OS/Arch: linux/arm64
Output of podman info --debug:
host:
arch: arm64
buildahVersion: 1.24.1
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.0-2.fc35.aarch64
path: /usr/bin/conmon
version: 'conmon version 2.1.0, commit: '
cpus: 1
distribution:
distribution: fedora
variant: coreos
version: "35"
eventLogger: journald
hostname: localhost.localdomain
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 1000000
uidmap:
- container_id: 0
host_id: 501
size: 1
- container_id: 1
host_id: 100000
size: 1000000
kernel: 5.15.18-200.fc35.aarch64
linkmode: dynamic
logDriver: journald
memFree: 1566859264
memTotal: 2048237568
networkBackend: netavark
ociRuntime:
name: crun
package: crun-1.4.2-1.fc35.aarch64
path: /usr/bin/crun
version: |-
crun version 1.4.2
commit: f6fbc8f840df1a414f31a60953ae514fa497c748
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
os: linux
remoteSocket:
exists: true
path: /run/user/501/podman/podman.sock
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: true
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.1.12-2.fc35.aarch64
version: |-
slirp4netns version 1.1.12
commit: 7a104a101aa3278a2152351a082a6df71f57c9a3
libslirp: 4.6.1
SLIRP_CONFIG_VERSION_MAX: 3
libseccomp: 2.5.3
swapFree: 0
swapTotal: 0
uptime: 9m 23.19s
plugins:
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
volume:
- local
registries:
search:
- docker.io
store:
configFile: /var/home/core/.config/containers/storage.conf
containerStore:
number: 0
paused: 0
running: 0
stopped: 0
graphDriverName: overlay
graphOptions: {}
graphRoot: /var/home/core/.local/share/containers/storage
graphStatus:
Backing Filesystem: xfs
Native Overlay Diff: "true"
Supports d_type: "true"
Using metacopy: "false"
imageCopyTmpDir: /var/tmp
imageStore:
number: 6
runRoot: /run/user/501/containers
volumePath: /var/home/core/.local/share/containers/storage/volumes
version:
APIVersion: 4.0.2
Built: 1646319530
BuiltTime: Thu Mar 3 08:58:50 2022
GitCommit: ""
GoVersion: go1.16.14
OsArch: linux/arm64
Version: 4.0.2
Package info (e.g. output of rpm -q podman or apt list podman):
n/a
Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)
No
Additional environment details (AWS, VirtualBox, physical, etc.):
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 22 (15 by maintainers)
PTAL: f37: https://bodhi.fedoraproject.org/updates/FEDORA-2023-20624cd618 f36: https://bodhi.fedoraproject.org/updates/FEDORA-2023-041092cd8f
Nice. Recommends qemu-user-static for workstation Recommmends qemu-user-static-ARM and X86_64 for Server. Suggests qemu-user-static for Server.
qemu-user-static is a huge package, we (I) recently broke it in to multiple different packages.
Perhaps we could recommends x86_64 and arch64 and then suggests the rest.
Pulling them all in by default seems way overkill.
The problem is we don’t have qemu-user-static installed on the fedora coreos machines by default. We need to make this happen automatically.
Hi @capnajax , Thanks for creating the issue. Adding
--platform=linux/amd64in build command makes sure that your base image will be pulled foramd64and your host arch isarmso binaries will getExec format error. In order to resolve this you need to setupqemu_user_staticandbinfmt_miscsee https://github.com/multiarch/qemu-user-staticIn case you are only interested in pulling
base imageforarmbut tagging final build asamd64you can use inline--platformto override pull arch see examples here https://github.com/containers/buildah/pull/3757 but I think you need the first one and i can tell this better if you can tell what is the intention of your build file.