Hey, On Fri, 2023-02-03 at 18:08 -0500, Daniel Walsh wrote:
On 2/3/23 16:08, Hendrik Haddorp wrote:
I also hoped that it just works and that toolbox sets up the environment in a way that podman/bulidah can be used. I did these steps: toolbox create fedora toolbox enter fedora sudo dnf install buildah podman buildah from scratch buildah mount working-container -> Error: cannot mount using driver overlay in rootless mode. You need to run it in a `buildah unshare` session
Currently, Toolbx doesn't set up the container in a way that podman(1) and buildah(1) will just work inside it. However, it's planned as part of an overall desire to make well-known tools, which usually need to run on the host, to work inside containers. Imagine if you were hacking inside a Toolbx container on a Fedora Silverblue host, and you need to use flatpak(1) or rpm-ostree(1) to quickly do something on the host. Remembering which terminal is running a shell on the host and which is inside a container can be annoying in the middle of a frantic hacking run. Similarly, your use- case, where Podman might be part of your hacking workflow. There's some discussion here and an initial implementation here: https://github.com/containers/toolbox/issues/145 https://github.com/containers/toolbox/pull/553 One easy way is to fake it: $ toolbox enter
flatpak-spawn --host podman images ... flatpak-spawn --host podman ps --all ...
This trick will work with many other tools: $ toolbox enter
flatpak-spawn --host flatpak list ...
In fact this is how Toolbx works inside Toolbx containers: $ toolbox enter
toolbox list ...
So, you could consider setting up some aliases inside your container to make this more palatable. I must admit that I haven't yet dug into the specifics of podman(1) and buildah(1) inside containers too deeply.
This can be handled by either setting up the toolbox to use a volume on ~/.local/share/containers
I saw that the Containerfile that you linked to has: VOLUME /var/lib/containers VOLUME /home/build/.local/share/containers I haven't played at all with volumes that aren't bind mounts of host paths, but I suppose this is a way to give the container a blank ~/.local/share/containers even if $HOME is a bind mount from the host? Or does it do something else? While Toolbx doesn't really use any namespace other than the user namespace, I wonder if this is enough to have a feature complete podman(1) running inside a container, or will we keep running into corner cases and limitations caused by running inside a container. Another consideration might be if people want to share their containers and images across all their Toolbx containers or not. Cheers, Rishi