podman run -it fedora bash doesn't give me a container shell. It's waiting endlessly, and also causes other processes to wait until I manually kill podman.
It is really bad for Silverblue users to have broken toolbox after upgrade. I don't understand why rhcontainerbot is used for stable releases. Let it play whatever that bot want in rawhide but please check thoroughly before pushing any update to stable releases.
For podman updates really why autopush is by default enabled? It MUST be manually pushed to stable by update submitter which should be real person.
I wonder what kind of testing has been done by +ve karma submitters here which all of other user's simple toolbox start test failure cannot be captured in their testing.
Please don't push podman releases like this to stable. Make toolbox start test mandatory to pass podman CI.
What about retracting this update? As is, it is still in stable, so when I run dnf update or dnf distrosync, this version of podman will get installed. Very annoying, because now I need to blacklist podman from updates, so that all other system updates can run through.
This update has been submitted for testing by rhcontainerbot.
This update's test gating status has been changed to 'failed'.
This update's test gating status has been changed to 'waiting'.
This update's test gating status has been changed to 'failed'.
This update has been pushed to testing.
This update's test gating status has been changed to 'passed'.
lsm5 edited this update.
podman run -it fedora bashdoesn't give me a container shell. It's waiting endlessly, and also causes other processes to wait until I manually kill podman.Seems generally functional. Also, happy to find
docker-composenow works rootless withdocker-compose -H unix:/run/user/1000/podman/podman.sockhmm, seems to work fine now. Maybe something on my end. Revising karma.
This update can be pushed to stable now if the maintainer wishes
works for me
passed FCOS tests: https://github.com/coreos/fedora-coreos-config/pull/1001
though I suspect we're not sending an rc to stable, which I think is correct.
This update has been submitted for stable by rhcontainerbot.
This update has been pushed to stable.
unable to start container after update https://github.com/containers/podman/issues/10274
Seeing the same on stable F34, Systemd files unable to start containers
unable to start container after update (OCI not found)
It is really bad for Silverblue users to have broken toolbox after upgrade. I don't understand why rhcontainerbot is used for stable releases. Let it play whatever that bot want in rawhide but please check thoroughly before pushing any update to stable releases. For podman updates really why autopush is by default enabled? It MUST be manually pushed to stable by update submitter which should be real person. I wonder what kind of testing has been done by +ve karma submitters here which all of other user's simple toolbox start test failure cannot be captured in their testing. Please don't push podman releases like this to stable. Make toolbox start test mandatory to pass podman CI.
The toolbox start fails with below messages DEBU[0000] Initializing event backend journald
DEBU[0000] configured OCI runtime runc initialization failed: no valid executable found for OCI runtime runc: invalid argument DEBU[0000] configured OCI runtime kata initialization failed: no valid executable found for OCI runtime kata: invalid argument DEBU[0000] configured OCI runtime runsc initialization failed: no valid executable found for OCI runtime runsc: invalid argument DEBU[0000] Using OCI runtime "/usr/bin/crun"
DEBU[0000] Default CNI network name podman is unchangeable INFO[0000] Setting parallel job count to 25
What about retracting this update? As is, it is still in stable, so when I run
dnf updateordnf distrosync, this version of podman will get installed. Very annoying, because now I need to blacklist podman from updates, so that all other system updates can run through.