Cannot cross build image to the target arm64 platform on amd64 host system when using RUN command in the containerfile

[odockal]

Bug description

I am trying to cross build an image from containerfile on amd64 host system to arm64 target platform. getting error:

Operating system

Windows 10

Installation Method

Installer from website/GitHub releases

Version

1.10.0

Steps to reproduce

0. Be on intel based machine, ie. amd64 arch.
1. Start up podman machine
2. Create a containerfile to build, ie:

FROM ghcr.io/linuxcontainers/alpine
RUN echo "Hello world!"

or

FROM fedora:39
RUN dnf install -y vim

3. Build an image using this containerfile -> pick up the file, context folder and image name
4. Choose to build image using ARM64 platform
5. Assert: image is built Actual:

Uploading the build context from C:\Users\podmanqe\fedora_images...Can take a while...
Building image-local-fedora...
STEP 1/2: FROM fedora:39
Resolving %!q(<nil>) to docker.io (enforced by caller)
Trying to pull docker.io/library/fedora:39...
Getting image source signatures
Copying blob sha256:22bb2152dc6386a1d2269ed00e37f29db25a6003edd92e1e785aace8b93f657c
Copying config sha256:40a32ce358f786e152609d399c331d807270e10783a70bfaaf654ac32fbb72a5
Writing manifest to image destination
STEP 2/2: RUN dnf install -y vim
exec container process `/bin/sh`: Exec format error
Error:building at STEP "RUN dnf install -y vim": while running runtime: exit status 1

Relevant log output

Uploading the build context from C:\Users\podmanqe\fedora_images...Can take a while...
Building image-local-fedora...
STEP 1/2: FROM fedora:39
Resolving %!q(<nil>) to docker.io (enforced by caller)
Trying to pull docker.io/library/fedora:39...
Getting image source signatures
Copying blob sha256:22bb2152dc6386a1d2269ed00e37f29db25a6003edd92e1e785aace8b93f657c
Copying config sha256:40a32ce358f786e152609d399c331d807270e10783a70bfaaf654ac32fbb72a5
Writing manifest to image destination
STEP 2/2: RUN dnf install -y vim
exec container process `/bin/sh`: Exec format error
Error:building at STEP "RUN dnf install -y vim": while running runtime: exit status 1

Additional context

No response

[benoitf]

could you please be sure to clean all the build cache before, I saw some bugs using buildah sometimes

podman system prune

[odockal]

Does not seem like the case.

[cdrage]

could you please be sure to clean all the build cache before, I saw some bugs using buildah sometimes

podman system prune

Looks like this is happening too on our "other extension" side. There is an issue posted regarding another error @odockal got.

When I did podman machine reset and recreated the machine it looks to have fixed it.

[benoitf]

I just tried on a macOS amd64 and it works

https://github.com/containers/podman-desktop/assets/436777/12942213-978e-4613-a908-39db418a9498

(it says aarch64 while I'm on a amd64 system)

[cdrage]

@odockal looks like it may be this issue: https://github.com/containers/podman/issues/19961 as I was able to replicate it myself.

macOS and Linux is it working fine.

Windows is unfortunately having issues building an arm image. It looks like a caching issue as per the last comment.

Only way is to reset the podman machine and try again it seems.

[benoitf]

in all case issue is not in podman desktop codebase so I would not make it as a blocker for 1.10.x

[odockal]

@cdrage @benoitf I believe that you are right. It might be out of control of podman desktop. although, if people will start build cross-platform images on windows, they gonna hit this. I have never managed on windows amd64 host to build image with target arch64 platform nor via podman desktop nor using cli.

Update: I am not saying this is blocking release, though.

[odockal]

Containerfile:

FROM fedora:39
RUN arch

cli command: podman build -t fedora-arch --platform=linux/amd64 .

Result is the same for pd and podman cli: Error: building at STEP "RUN arch": while running runtime: exit status 1

[odockal]

@cdrage @benoitf The workaround suggested in the last comment make it work!

[odockal]

Workaround:

podman machine ssh
curl https://raw.githubusercontent.com/qemu/qemu/master/scripts/qemu-binfmt-conf.sh > qemu-binfmt-conf.sh
chmod +x qemu-binfmt-conf.sh
sudo mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc
sudo ./qemu-binfmt-conf.sh --qemu-suffix "-static" --qemu-path "/usr/bin" -p yes
exit

podman build -t fedora-arch --platform=linux/arm64 .
STEP 1/2: FROM fedora:39
STEP 2/2: RUN arch
aarch64
COMMIT fedora-arch
--> 0b4b09c0e454
Successfully tagged localhost/fedora-arch:latest
0b4b09c0e45452807989881064fa4b94741246e2bc39ab29a91e38b2700256f7

[benoitf]

OK so definitely a podman issue. We might ask them to see if they can fix it in the podman machine

[benoitf]

I think it requires fixes but only in the machine

[benoitf]

https://github.com/containers/podman-machine-wsl-os/blob/main/.cirrus.yml probably a patch there

[benoitf]

Adding os/Windows label to the issue as it's windows specific ( on macOS it works as expected)

[benoitf]

removing 1.10.1 milestone and created https://github.com/containers/podman/issues/22883