podman machine os apply command should abort if arch is different #19851
Comments
|
@ashley-cui can you take a look? |
This one's for me :) EDIT: For context, @benoitf is trying the new fcos image build using packages from podman-next that we'll be publishing to |
|
@benoitf does it work with an image you have built? |
|
@baude let me check |
|
so I built an image quay.io/fbenoit/coreos-podman:2023-09-05 using https://github.com/coreos/layering-examples/blob/main/podman-next/Containerfile (removing conmon package from the list else image can't be built) and it worked |
|
@benoitf did you have dependency issues with conmon? I thought I got rid of all the problem builds from the copr. Could you please post any relevant logs? |
|
@lsm5 I applied the following patch diff --git a/podman-next/Containerfile b/podman-next/Containerfile
index f284c76..988ca58 100644
--- a/podman-next/Containerfile
+++ b/podman-next/Containerfile
@@ -11,6 +11,6 @@ COPY rhcontainerbot-podman-next-fedora.gpg /etc/pki/rpm-gpg/
# Note: Currently does not result in a size reduction for the container image
RUN rpm-ostree override replace --experimental --freeze \
--from repo="copr:copr.fedorainfracloud.org:rhcontainerbot:podman-next" \
- aardvark-dns conmon crun netavark podman containers-common containers-common-extra && \
+ aardvark-dns crun netavark podman containers-common containers-common-extra && \
rpm-ostree override remove moby-engine containerd runc && \
ostree container commitelse I have let me try now with the podman's copy of this Containerfile at https://github.com/containers/podman/tree/main/contrib/podman-next/fcos-podmanimage |
|
ack, btw there are still some issues in the GitHub Actions for building the fcos image that I'm working through right now. I'll update here once I have a |
|
so, I was able to build successfully https://github.com/containers/podman/blob/main/contrib/podman-next/fcos-podmanimage/Containerfile instead of https://github.com/coreos/layering-examples/blob/main/podman-next/Containerfile I built it, pushed it to was able to stop and start the machine but it's always failing to restart using I also tried on a fresh machine (so this time the image is not already on the podman machine) it's also working so on my side it seems to be specific to the image published |
|
looking at the difference I think the issue is that the image published by the CI is a x64 image while my image is a ARM64 image (as my system) |
|
so |
|
and probably |
|
@cevich remind me, is there any special handling involved to build multi-arch image? Also, are multi-arch image issues fixed or still pending? don't remember if that was a cirrus or quay thing. |
benoitf
changed the title
|
I've updated the title of the issue and the description |
|
Hmm, Is this issue better fixed in rpm-ostree? |
|
@ashley-cui I don't know who is responsible of doing what but yes at the end user think it might work while it doesn't so process should fail before. |
|
For now the issue is that the image build in the new github actions addition didn't work as expected which the linked PR should fix once complete. |
|
@rhatdan @vrothberg here we have again another example of podman just doing whatever and not helping our users. when i am back from PTO (and @vrothberg is as well), ill huddle us once and for all on this topic. thanks @benoitf |
|
We cannot enforce platform checks by default (see #12682 for details). We tried it a number of times and immediately broke users. The biggest problem is that some images claim to be of a different architecture. There were bugs in practically all tools causing "wrong platforms" (e.g., Podman/Buildah, Docker, buildkit). We've tried enforcing in c/image and in libimage etc. and every time we enforced platform checks, things broke in the wild immediately. I think it boils down to adding an |
|
In this instance, since the image is from a remote registry, we're letting rpm-ostree take care of the pulling as well as the rebase. Podman isn't directly doing the pulls, so unless we make a different call to check arch before letting rpm-ostree do the pull. I think the better option is to have this implemented in rpm-ostree, but I can see letting podman check the arch as a temporary workaround. |
|
can we all please hold off any further discussion until we get the linked PR in? I'm working on building a multi-arch image in github actions https://github.com/containers/automation_sandbox/actions/runs/6097256491/job/16544521868 . Once that's done, we should be good to go. |
|
@lsm5 users could reference other images that they're building, etc. Issue is still there (just that it'll work for the referenced image). And when it happens, the podman machine is stuck/broken we can't recover |
ohh, then I gotta remove the linked PR and let @baude @vrothberg @ashley-cui handle that separately. My apologies. |
|
All good, thanks @lsm5 for updating the podman-next image :) |
|
but anyway yes @lsm5 thanks for fixing the image |
|
btw, final update from my side here and then I'll stop making noise. amd64, arm64 multiarch image is available at: https://quay.io/repository/podman/fcos?tab=tags&tag=latest . The expiration doesn't look correct, I'll fix that soon. But hopefully the image should work. EDIT: Continuing my GHA fix in #19877 |
|
@lsm5 FYI the current image works like a charm |
|
could the version contains the git sha ?
|
is |
btw, I think I can make this happen, just wanna confirm that API Version will also say: |
|
@lsm5 yes it's available on the podman machine but basically we don't connect to the machine in ssh, we run CLI on the host/macOS computer For example if I run the so I would be fine if there was a Git Commit section for the server part as well |
|
A friendly reminder that this issue had no activity for 30 days. |
|
closing |
stale-locking-app
bot
added
the
locked - please file new issue/PR
Issue Description
There is a FCOS image including podman available at https://quay.io/repository/podman/fcos?tab=tags
but this image is a x64 image
Then if I ran the command to apply this podman version but then restarting the machine is failing
it's because my system is an arm64 system and it tries to change packages to its x64 counterpart.
the command
os applyshould detect and abort the sequence if platform arch and image arch are not matchingSteps to reproduce the issue
Steps to reproduce the issue
But then I restart the podman machine
but it's never booting
qemu process is at 99-100%
I also tried on a fresh machine (no container, etc)
Describe the results you received
error
Describe the results you expected
podman machine using the recent podman's version
podman info output
If you are unable to run podman info for any reason, please provide the podman version, operating system and its version and the architecture you are running.Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: