Evaluate rootless non-systemd workaround option #92
Conversation
* podman 5.1.1 * drop CNI networking and slirp4netns in favour of netavark + pasta * build statically linked netavark, pasta and aardvark * conmon 2.1.11 * crun 1.15 * crun is also shipped with the normal (non-minimal) image now. * build using golang 1.22, use alpine 3.19 base container
| @@ -102,7 +102,6 @@ tar: .podman-from-container | |||
| rm -rf $(ASSET_DIR) | |||
| mkdir -p $(ASSET_DIR)/etc $(ASSET_DIR)/usr/local | |||
| cp -r conf/containers $(ASSET_DIR)/etc/containers | |||
| cp -r conf/cni $(ASSET_DIR)/etc/cni | |||
There was a problem hiding this comment.
ah, good point!
I added this change to my PR now.
| setup_file() { | ||
| # Workaround for rootless non systemd github.com/containers/common/pull/2042/commits/67fdd8bd3aa912efa9d8a6375c6b5d192d4f8f9a | ||
| #mkdir -pm1777 "$PODMAN_ROOT_DATA_DIR/../../../rootless-netns/run" | ||
| mkdir -pm700 "/tmp/storage-run-1000/containers/networks/rootless-netns/run" |
There was a problem hiding this comment.
I don't think this is the right place to apply the workaround since it needs to be applied within the docker container, not on the host.
There was a problem hiding this comment.
Although, there seems to be a mount when starting the container on the host for /tmp/storage-run-1000/containers/networks/rootless-netns/run to be at /run (presumably within the container) right now, but might've misunderstood the log.
# (in test file test/rootless.bats, line 63)
# `$DOCKER run --rm --privileged -u podman:podman \' failed with status 125
# [starting container c0b254a4e5292dd407e3b5dfd75172b817a40f338930406cc342d88bd6cae085: rootless netns: mount "/tmp/storage-run-1000/containers/networks/rootless-netns/run" to "/run": no such file or directory]
# [starting container c0b254a4e5292dd407e3b5dfd75172b817a40f338930406cc342d88bd6cae085: rootless netns: mount "/tmp/storage-run-1000/containers/networks/rootless-netns/run" to "/run": no such file or directory starting container b9f298597a85b5663369f63657d078e97bc91e466dbf8c444e32fe518c2531b4: a dependency of container b9f298597a85b5663369f63657d078e97bc91e466dbf8c444e32fe518c2531b4 failed to start: container state improper]
# Pod:
# d9b65d6dc6b4920a40258fc086bfb248047a0e4bc26b47d94acff0f556fc540b
# Container:
# b9f298597a85b5663369f63657d078e97bc91e466dbf8c444e32fe518c2531b4
#
#
# starting container c0b254a4e5292dd407e3b5dfd75172b817a40f338930406cc342d88bd6cae085: rootless netns: mount "/tmp/storage-run-1000/containers/networks/rootless-netns/run" to "/run": no such file or directory
# starting container b9f298597a85b5663369f63657d078e97bc91e466dbf8c444e32fe518c2531b4: a dependency of container b9f298597a85b5663369f63657d078e97bc91e466dbf8c444e32fe518c2531b4 failed to start: container state improper
Making a path within the specified container it is trying to start would definitely suffice as this was a suggestion (which is what I would pursue if this does not work, but initially it seemed plausible that addressing the mount may allow /run/ to exist in the container).
There was a problem hiding this comment.
It is not straightforward to know exactly the execution context of this. Although trying it may yield some more information. At the same time – this build takes a long time right now. I did not get a chance to look through all the changes that are on this branch yet (before allowing it to run a restricted set of actions on my fork / repo).
There was a problem hiding this comment.
Though, I can confirm applying it within the docker container makes the test pass.
There was a problem hiding this comment.
Although, there seems to be a mount when starting the container on the host for /tmp/storage-run-1000/containers/networks/rootless-netns/run to be at /run (presumably within the container) right now, but might've misunderstood the log. https://github.com/mgoltzsche/podman-static/actions/runs/9377299921/job/25818642965#step:5:2804
Indeed, /run within the log message refers to the container's file system.
There was a problem hiding this comment.
I think it just worked – by that I mean it allowed the test to pass by indirectly following the workaround suggestion.
I may be slightly skeptical of something like this working on the first attempt. 😂
There was a problem hiding this comment.
Well I ran the e2e tests on my machine first (where turnarounds are a lot faster) to verify that the workaround works 😄.
|
Thanks for creating the PR! I added the CNI related change to my PR #91 as well as a workaround for the |
Attempt a workaround option on the e2e test for /run not mounting to path container image.