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   podman run fedora   -> fails because /etc/subuid is not setup in the toolbox   sudo usermod --add-subgids 10000-65536 haddorp   sudo usermod --add-subuids 10000-65536 haddorp   podman run fedora   -> fails as newuidmap is not setup   sudo setcap cap_setuid+eip /usr/bin/newuidmap   sudo setcap cap_setgid+eip /usr/bin/newgidmap   podman run fedora   -> ERRO[0000] invalid internal status, try resetting the pause process with "podman system migrate": cannot re-exec process to join the existing user namespace do you have steps that work? thanks, Hendrik On 03.02.2023 22:50, Daniel Walsh wrote:

On 2/3/23 15:38, Hendrik Haddorp wrote:

...

Hi,

I want to create a custom toolbox (https://github.com/containers/toolbox) image and use rootless buildah inside the container created by toolbox on Fedora. Are there any instructions on that? Or maybe an example?

thanks, Hendrik _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io

It should just work as long as you have /etc/subuid and /etc/subgid defined in the toolbox and have enough UIDs and GIDs available.

It never hurts to look at

https://github.com/containers/buildah/blob/main/contrib/buildahimage/Contain...

To see how we configure Buildah to run within a container. _______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io

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