podman: "Could not get runtime: unknown event logger type" on Fedora 31 Beta Silverblue

At this point, I would recommend removing $HOME/.config/containers/libpod.conf entirely, so Podman will automatically re-generate it from the root defaults - that should get you a working system.

@rhatdan FYI - it looks like the migration code ran, but he doesn’t have the new runtime paths sections (older Podman generated this config), so the migration to crun failed.

Still had this issue in Podman v1.6.2 and needed to delete libpod.conf 😕

1.6.2 should now be in the Fedora 31 repos. I believe it will be available in the default install, and will not require a day 1 upgrade.

For folks finding this from a search engine, if you encounter difficulty launching containers after an upgrade to F31, we recommend the following:

• Whenever possible, remove containers created in older Fedora versions and recreate with F31 Podman - this is inconvenient, but the safest option
• If you have containers you do not wish to recreate, you can run podman system migrate --runtime crun to convert them to work on Fedora 31. There is, however, a chance that some containers will not work after the migration.
• If you encounter issues where Podman will not launch due to an unknown event logger, we recommend removing $HOME/.config/containers/libpod.conf (assuming you have not modified your copy). Podman will regenerate the configuration file with sane defaults for F31.

Closing this as such. Feel free to open new issues with any further migration difficulties that appear.

We’re planning a new Podman release with solutions to most migration issues. Hopefully these issues are serious enough for a freeze exception and we’ll be able to get it into the F31 final compose. If not, it’ll be a very early update.

On Wed, Oct 16, 2019, 03:40 Zlopez notifications@github.com wrote:

@GoodMirek https://github.com/GoodMirek I absolutely agree with you.

There are two issues that will be unfortunate for any user upgrading to F31. This one, where you need to regenerate $HOME/.config/containers/libpod.conf and the regression in podman create which will prevent you to use any previously created container. I personally thought that this was solved together with containers/toolbox#277 https://github.com/containers/toolbox/issues/277, but it seems that this affects every user who does update from F30 to F31. I’m not sure if there is time to actually do anything about it when the release of F31 is closing up.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/containers/libpod/issues/4210?email_source=notifications&email_token=AB3AOCE3RXDMSELUVUPGWETQO3ANRA5CNFSM4I6BMWYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBLO2NA#issuecomment-542567732, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3AOCBTOPME6BIGRUXVQ7LQO3ANRANCNFSM4I6BMWYA .

Same issues here even after all workarounds in this thread. I don’t want to add fuel to the fire here but if Podman is going to snuff out Docker, it’s clearly not ready yet and maybe the crippling cgroup changes need to go back into Beta (or Rawhide) until it is. OpenShift? Broke. Containers? Broke. This not a good strategy.

 jboero  xps  ~  $  podman ps
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
 jboero  xps  ~  $  docker ps
Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
CONTAINER ID  IMAGE  COMMAND  CREATED  STATUS  PORTS  NAMES
 jboero  xps  ~  $  oc cluster up
Getting a Docker client ...
Checking if image openshift/origin-control-plane:v3.11 is available ...
error: unexpected error inspecting image openshift/origin-control-plane:v3.11
 jboero  xps  ~  $ 

Workaround In the end, I needed to default back to Docker by adding systemd.unified_cgroup_hierarchy=0 kernel param. In fact grubby is also broken now so I needed to manually add it in /etc/default/grub and grub2-mkconfig -o /boot/grub2/grub.cfg and reboot. Then docker (now moby v18) works again and so does OpenShift / origin.

I have a similar issue in Fedora 31, where podman is working under root but as user I receive the following error:

‘’’ Error: could not get runtime: unknown event logger type: ‘’’

I ran the command to migrate to the new runtime but the problem persists. Also, there is no libpod.conf.

F31 upgrade, podman v1.6.2, libpod.conf removed, running rootless, and now trying to start a previously stopped container:

08:25 $ podman  start pg11
Error: unable to start container "pg11": systemd cgroup flag passed, but systemd support for managing cgroups is not available: OCI runtime error

Inspecting:

08:28 $ podman inspect pg11 | rg cgroup -A 2 -B 2
            "--log-level",
            "error",
            "--cgroup-manager",
            "cgroupfs",
            "--tmpdir",
            "/run/user/1000/libpod/tmp",

This was working on F30.

Same issue here, happened after upgrade from FC30 Workstation (dnf based) to FC31 Workstation (dnf based). After removing $HOME/.config/containers/libpod.conf entirely, i can run podman version, but cannot start any of my old pet containers (e.g. toolbox) and have to remove and recreate them.

I tried to add the two lines and got this

Error: could not get runtime: error decoding configuration file /home/zlopez/.config/containers/libpod.conf: Near line 26 (last key parsed 'events_logger'): Key 'events_logger' has already been defined.