-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compose not working after upgrade to 4.6.2 #19930
Comments
I can reproduce on fedora 38 with |
@mheon PTAL |
This is a nonfatal error on rootless (it's always happened, but always just printed to the journal and was ignored). So either it suddenly became fatal, or the real error is being eaten. Can you stop |
This is the debug log of
|
Anything in the journal logs from Conmon? |
Not much information that isn't already contained in the podman logs:
Retrieved by simply running |
Can you try to downgrade crun? This sounds like crun issue containers/crun#1302. |
it is fixed by #19843 |
crun was previously ignoring The root cause is docker-compose hardcoding the value to 0, so we added the workaround to Podman. As a temporary fix you can downgrade crun, alternatively tweak systemd to run user sessions with oom_score_adj=0 |
Hi, thanks you for solve this problem |
Just FYI: I see the same on the latest Fedora 38, while trying to use testcontainers.org library with podman's user socket. |
@Rtapy you can run |
For Fedora 38, you can install crun 1.8.7 with:
|
If you have the old package in the pacman cache (arch linux)
|
Hi! I'm using podman with podman machine on MacOS. Trying to figure out the right way to rollback crun. The default machine is Fedora CoreOS (maybe this can be swapped, but like to keep things as vanilla as possible). I haven't used CoreOS much at all since I prefer for this stuff to be transparent, but I looked at the docs for rolling back the image and found this command, but there's nothing to rollback to.
Found via: Any recommendations for a workaround on MacOS?
I also tried downgrading podman and resetting the machine but the image appears to have the new engine installed anyway. Maybe theres a way I can specify which image version I want to download with podman? I haven't found that yet. |
Found this: https://fedoraproject.org/coreos/release-notes/?arch=x86_64&stream=stable Had to manually download the old image using url hacking because there doesn't seem to be links from the release notes pages.
That worked! 🎉 Freaking love the simplicity of podman. Even with obscure error messages like the one thrown, wasn't so bad to dig into the issue and find out how to fix it. Great work team! Maybe sometime I'll learn rpm-ostree, but I'll save that for a later date. :-)
Time to try again. Raced podman machine init with podman machine ssh then ran this when I got a shell:
Seems to have worked 🤞.
|
Podman 4.7.0 is releasing today with a fix allowing the most recent crun version to be used. Closing as such. |
This has been fixed in podman 4.7.0 containers/podman#19930 (comment)
@ankon it's the same issue, I just didn't include the log from the podman vm |
(this is how it manifests client-side) |
4.7 should land in Fedora stable in the next few days, and from there will land in FCOS in at most 2 weeks (could be sooner, AFAIK they run on a 2 week cycle over there). |
I also upgraded to Podman 4.7.0 and am still receiving the |
As stated above you need v4.7 on the server side, you can check with |
I'm on Bazzite, not CoreOS. |
Let's see if this fragile nonsense breaks again. What was here though was hiding containers/podman#19930 (i.e. a real 500 error coming from a podman bug which was being reported as the image not existing).
@mheon do you know when this hits centos appstream? |
4.7 probably does not hit CentOS stream since it's not destined for RHEL (it's a purely upstream release). Next RHEL release is probably 4.9 (with 4.8 coming out ~late November, and 4.9 early next year). |
Looks like |
I disagree. Podman |
I am not sure if this is helpful (but it might be to future Googlers): I got a 'false positive' of sorts where I ran into both of the above errors ( |
…man. This effectively fix errors like "unable to upgrade to tcp, received 409" like containers#19930 in the special case where podman itself is running rootful but inside a container which itself is rootless. [NO NEW TESTS NEEDED] Signed-off-by: Romain Geissler <[email protected]>
…man. This effectively fix errors like "unable to upgrade to tcp, received 409" like containers#19930 in the special case where podman itself is running rootful but inside a container which itself is rootless. [NO NEW TESTS NEEDED] Signed-off-by: Romain Geissler <[email protected]>
…man. This effectively fix errors like "unable to upgrade to tcp, received 409" like containers#19930 in the special case where podman itself is running rootful but inside a container which itself is rootless. [NO NEW TESTS NEEDED] Signed-off-by: Romain Geissler <[email protected]>
…man. This effectively fix errors like "unable to upgrade to tcp, received 409" like containers#19930 in the special case where podman itself is running rootful but inside a container which itself is rootless. [NO NEW TESTS NEEDED] Signed-off-by: Romain Geissler <[email protected]>
Issue Description
After upgrading to podman 4.6.2 I cannot use
docker-compose
anymore to launch any containers. Launching containers usingpodman run
works fine however.Steps to reproduce the issue
Steps to reproduce the issue
Describe the results you received
The following error occurs:
Describe the results you expected
Should just spawn an nginx image. This still works by running
podman run --rm nginx:alpine
podman info output
The text was updated successfully, but these errors were encountered: