The "Test install" job's `priv-integration.sh` step hangs
intermittently at the chunkah build (a nested `podman run` invoked via
`systemd-run -dP --wait`). The root cause is not fuse-overlayfs
performance or the chunkah build itself: it's that the outer
`sudo podman run --privileged --pid=host ...` invocation bind-mounts
the HOST's real systemd and dbus sockets in
(`-v /run/dbus:/run/dbus -v /run/systemd:/run/systemd`), so every
`systemd-run` call inside the container talks to the host's actual
systemd manager rather than anything scoped to the container.

`systemd-run --wait` asks systemd to fork and supervise the wrapped
command, and with the host's real systemd manager on the other end of
that dbus call, the forked process ends up living in the HOST's mount
and IPC namespaces instead of the container's -- despite having been
launched from inside the privileged container. When that escaped
process is itself a `podman run` (as with the chunkah build), it
starts contending on host-level podman locks (e.g.
`/dev/shm/libpod_lock`) against the *actual* host-level `sudo podman
run --privileged` process that is itself still running the CI job,
which deadlocks forever.

This was tracked down empirically: comparing `/proc/<pid>/ns/mnt` and
`/proc/<pid>/ns/ipc` of the hung process against host PID 1 confirmed
the escape, and reproduced the hang reliably in isolation by stripping
priv-integration.sh down to just the chunkah step. None of the four
`systemd-run -dP --wait` call sites here actually need systemd
supervision: they're synchronous builds/copies (`podman build`, two
`skopeo copy` calls, and the chunkah `podman run`) that work fine run
directly, and were apparently only wrapped in systemd-run to get a
cgroup for the nested container.

Fixing this isn't just a matter of deleting those wrappers, though.
`/run/dbus` can go entirely -- nothing here ever dials it once
systemd-run is gone -- but `/run/systemd` has to stay mounted, because
the `nsenter -m -t 1 journalctl _COMM=bootc` check a few lines above
this depends on it: ostree-ext's structured logging silently skips
writing to the journal at all unless `libsystemd::daemon::booted()` (a
check for `/run/systemd/system`) is true, and this test's own "layers
already present" assertion relies on that write happening. But leaving
/run/systemd mounted for the whole script also breaks cgroup
delegation for the nested podman invocations below (podman's
cgroup-manager auto-detection only produces a working, fully delegated
`cgroupfs` setup when it can't see a live systemd socket at all) --
and that turns out to hold regardless of `--cgroup-manager` flags at
any level, since it's decided dynamically per invocation rather than
once at container-creation time.

So instead: keep /run/systemd mounted at container creation for the
journal check, then have priv-integration.sh itself unmount it right
after that check, before any of the systemd-run-free podman/build work
that follows. Verified with the same namespace comparison that the
nested chunkah process's mnt/ipc namespaces match the outer
container's own entrypoint rather than the host's, and with a full,
unmodified end-to-end run of priv-integration.sh that both the journal
check and the final "ok privileged integration" line pass.

Assisted-by: AI
Signed-off-by: Colin Walters <walters@verbum.org>

Signed-off-by: Pragyan Poudyal <pragyanpoudyal41999@gmail.com>