Comments

32 Comments

The user-runtime-dir.service fails on Fedora Silverblue making Wayland unavailable and systemd --user unusable.

× user-runtime-dir@1000.service - User Runtime Directory /run/user/1000
     Loaded: loaded (/usr/lib/systemd/system/user-runtime-dir@.service; static)
     Active: failed (Result: exit-code) since Wed 2022-01-19 16:41:21 EET; 4min 32s ago
       Docs: man:user@.service(5)
    Process: 1540 ExecStart=/usr/lib/systemd/systemd-user-runtime-dir start 1000 (code=exited, status=1/FAILURE)
   Main PID: 1540 (code=exited, status=1/FAILURE)
        CPU: 18ms

tammi 19 16:41:21 marty-t460 systemd[1]: Starting User Runtime Directory /run/user/1000...
tammi 19 16:41:21 marty-t460 systemd-user-runtime-dir[1540]: mmap: Permission denied
tammi 19 16:41:21 marty-t460 systemd-user-runtime-dir[1540]: Failed to mount per-user tmpfs directory /run/user/1000: No such file or directory
tammi 19 16:41:21 marty-t460 systemd[1]: user-runtime-dir@1000.service: Main process exited, code=exited, status=1/FAILURE
tammi 19 16:41:21 marty-t460 systemd[1]: user-runtime-dir@1000.service: Failed with result 'exit-code'.
tammi 19 16:41:21 marty-t460 systemd[1]: Failed to start User Runtime Directory /run/user/1000.

Tested with a number of old + new containers and all seem to be working alright.

BZ#1995439 /usr/bin/toolbox linked against glibc-2.34 doesn't run on older glibc

Mmm... I think all (even old) toolbox containers have /run/host inside of them. I think the real problem that there is no /run/host/lib64 in those containers as that started to be done not that long ago (as part of mounting the whole root filesystem of the host into /run/host). I also have such a container around.

@cheeselee, could you provide some logs from the breakage of the containers? My impression was that the fix should work even with existing containers.

Experiencing hangs of graphics. Just sudden freeze of the display. Audio continues but no keyboard/mouse activity has any effect.

Happened several times and found these lines in the journal:

Sep 09 16:54:48 marty-t460 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85df1cff, in Renderer [2935]
Sep 09 16:54:48 marty-t460 kernel: i915 0000:00:02.0: [drm] Renderer[2935] context reset due to GPU hang
Sep 09 16:54:48 marty-t460 kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Sep 09 13:05:10 marty-t460 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 9:1:85dffffb, in Renderer [16391]
Sep 09 13:05:09 marty-t460 kernel: i915 0000:00:02.0: [drm] Renderer[16391] context reset due to GPU hang
Sep 09 13:05:09 marty-t460 kernel: i915 0000:00:02.0: [drm] Resetting rcs0 for preemption time out
Sep 09 13:05:08 marty-t460 kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1558]:aeb38 timed out (hint:intel_atomic_commit_ready [i915])
karma

This has been previously tested with Fedora Rawhide (34) image and has worked out well.

karma

This has been previously tested with Fedora Rawhide (34) image and has worked out well.

Based on the bug reporter's comment, the rebuilt image works on aarch64 system.

BZ#1912114 Missing aarch64 container

Toolbox seems to be working alright with this version of Podman. Creating, entering, removing containers works.

I tried with Toolbox and the GPG key issue is gone.

karma

I agree with @rishi on postponing this release due to https://github.com/containers/podman/issues/7389

I believe my testing in FEDORA-2020-885e55baff also applies to this update.

BZ#1858974 Containers don't start on Fedora CoreOS because there's no 'sudo' group inside the container
BZ#1867829 sudo(8) inside toolbox containers asks for a password with Podman 2.0.5