Bug 2066527

Can you try with `--runtime=crun` and see if that works? That should be the default OCI runtime for Podman, and unless you've deliberately configured runc as the default runtime, the fact that it seems to be default in F36 is somewhat concerning.

[adamw@xps13k blockerbugs (develop %)]$ podman run --runtime=crun --detach --name blockerbugsdb2 --env POSTGRES_PASSWORD=blockerbugs --env POSTGRES_DB=blockerbugs --env PGDATA=/var/lib/postgresql/pgdata --publish 5433:5433 docker.io/library/postgres:13
Error: default OCI runtime "crun" not found: invalid argument

name and ports changed so as not to conflict with the 'real' one that's running via sudo.

After a `dnf -y install crun`, it works, even without --runtime:

[adamw@xps13k blockerbugs (develop %)]$ podman run --detach --name blockerbugsdb2 --env POSTGRES_PASSWORD=blockerbugs --env POSTGRES_DB=blockerbugs --env PGDATA=/var/lib/postgresql/pgdata --publish 5433:5433 docker.io/library/postgres:13
249daf6e175cc6c7466ba8cc68ffcf9e2e6fd8d3a92bf646a5bf6836d04de75d

so, I guess the bug here was "crun wasn't installed". How were you expecting it to be pulled in?

[adamw@xps13k blockerbugs (develop %)]$ rpm -q --whatrequires crun
no package requires crun
[adamw@xps13k blockerbugs (develop %)]$ rpm -q --whatrecommends crun
no package recommends crun
[adamw@xps13k blockerbugs (develop %)]$ rpm -q --whatsuggests crun
no package suggests crun
[adamw@xps13k blockerbugs (develop %)]$ 

It seems to me that both runc and crun provide oci-runtime, which is what podman requires (via containers-common). On a long-deployed system like mine - where runc has probably been installed for a long time - there's nothing that would prompt the system to switch to crun on an update. Even for a fresh install, I can't see any 'hints' in the containers-common spec to try and make it prefer crun, so whether runc or crun gets installed to satisfy this dependency seems to be left entirely to the whims of dnf (which are, uh, whimsical). Even if it happens to pick crun right now, there is nothing to guarantee this that I can see, so a chance gust of wind or change in the phase of the moon might make it switch to picking runc...

I don't think the expectation is that systems that once had runc will be automatically upgraded, so this sounds expected: they should both be supported, with a preference for `crun` on fresh installations; so if this system was upgraded from an older Fedora that did default to `runc`, it sounds like everything is working as expected, which is a relief.

Also, given that Podman is working fine when `crun` is in use, I'm going to change component to `runc` - seems like there's an issue with the OCI runtime here.

But as I said, AFAICS there is no "preference for `crun` on fresh installations" expressed anywhere. It seems to be left entirely up to dnf to decide, unless I'm missing something.

Yes crun wins because of the alphabet, I believe.

The heuristic that gets used (I forget whether it's in libdnf or libsolv or what...) is kind of obscure and has changed before. I wouldn't want to rely on that if a specific outcome is desired. If the alphabetical order is still used, IIRC, it's only as a kind of last-ditch tiebreaker, it uses other things first. For instance, IIRC, a provider that pulls in a smaller set of dependencies is preferred over one that pulls in a larger set of dependencies.

We probably should change containers-common to recommends crun. or at least suggests it.

Yeah, I believe that's how you're supposed to do this. A Suggests: should be sufficient for dnf to take it as a hint, I think. CCing some DNF folks for confirmation - where "foo" requires "bar", and there are two providers of "bar" but we want one of them to be preferred unless the user decides otherwise, is it correct to make foo Suggests: the preferred provider? Thanks!

I just started hitting this on CentOS Stream 8 too - just today, after a reboot, despite 'dnf history' not showing any relevant changes.

❯ rpm -q containers-common podman
containers-common-1-23.module_el8.7.0+1106+45480ee0.x86_64
podman-4.0.2-1.module_el8.7.0+1106+45480ee0.x86_64

Interestingly, after installing crun, podman still seems to prefer runc unless I pass `--runtime=crun`:

podman run --runtime=crun --rm -ti --ipc host --network host --privileged --security-opt label=disable --user root:root --pid host --userns keep-id --ulimit host --annotation run.oci.keep_original_groups=1 --mount type=devpts,destination=/dev/pts alpine:latest sh


and I can't remove runc as it's a hard dependency.

❯ rpm -q --requires podman | grep runc
runc >= 1.0.0-57

You can change the default runtime to crun in containers.conf.

the packaging was changed in the last year to prefer crun. Does this issue still occur ?

This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16.

Fedora Linux 36 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.