Cannot do cross-platform builds from Dockerfiles with RUN commands
#13924
Comments
github-actions
bot
added
macos
|
Hi @capnajax , Thanks for creating the issue. Adding In case you are only interested in pulling |
|
Hi, @flouthoc thank you for responding so quickly and telling me about the Yes, I am intentionally pulling an I am assuming this has to do with the virtualization engine behind Docker/Podman as the only layers that should have to execute a command inside the container at build-time are all |
|
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. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
A friendly reminder that this issue had no activity for 30 days. |
|
qemu-user-static is now partially installed on fcoreos, so this should work at least for building X86 from an M1 or Arm from an X86 machine. |
|
Wow podman actually supports cross builds, nice work, it just needs some polishing. (I actually planned on ditching it and installing docker instead when I saw this error -.-) Could podman just recognize that the |
|
I could see us adding it as a suggests, but do you think this would help people discover it? |
|
It would need to be a recommends, a suggests wouldn't do a thing, if I understand this correctly. "Recommends" would install qemu-user-static like a "Requires" dependency by default but still allows users to ignore/uninstall it if they wish to save space. I personally prefer a "all batteries included" approach when I install packages, I have enough bandwidth and storage to spare for the occasional unused dependency. On the other hand, this may not be true for all users and many will probably only build images for their local machine and never need qemu-user-static. Considering this I think the best approach would be to detect the missing package when it is needed and inform the user about this. |
|
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. |
|
@lsm5 WDYT? |
|
@rhatdan fedora-server (and I think also fedora-cloud) will likely ignore Recommends and Suggests. If it exists already on fcos, then we could have it as a Recommends on desktop and Requires on server. I'm guessing Recommending (on desktop) / Requiring (on server) for all arches supported by fedora and suggests for the other arches, but I'm also fine with recommending only x86_64 and aarch64 and suggesting the rest. |
|
Yes understood that fcos will ignore both, we have requested that they be added. If we can differentiate desktop from server, that would be fine, although I am not sure the complexity is worth it. |
|
we already do it in containers-common, so should be ok I guess. |
|
Nice. |
|
Recommends and suggests will be ignored for server by default, so they have to be Requires, if at all. This is what I'm thinking for now: |
|
@rhatdan btw does qemu-user-static-x86 include x86_64? I don't see a separate package for x86_64. |
|
I have no idea, but I would figure. |
|
Just tried it on Fedora 37 workstation: DNF shows all the arches als Depencencies and only the meta packages as weak dependency. Probably a bug in DNF showing weak dependency's dependencies in the wrong category. (Shall we report that?) I'm allowed to remove those, keeping only aarch, x86 and arm: Great stuff, many thanks to both of you! ❤️ |
|
@credativ-dar ack, thanks for testing and good to know it's working for you. Looks like hard dependencies of weak dependencies get listed as hard dependencies, I see the same on my side. I do agree those should get listed under weak dependencies. Anyway, we'll keep this dependency setup unless and until people complain :) . |
github-actions
bot
added
the
locked - please file new issue/PR
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
RUNcommand in it. The build always fails when it reaches theRUNcommand.Steps to reproduce the issue:
RUNcommand in it.RUNstepDescribe the results you received:
The image failed to build with an Exec format error, the same error I would expect if I deployed an
armcontainer on anamd64machine.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:Output of
podman info --debug:Package info (e.g. output of
rpm -q podmanorapt 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.):
The text was updated successfully, but these errors were encountered: