#1

Hi.

I’m starting to try fedora-toolbox before migrating to Silverblue and apparently I can’t run podman commands (so probably no buildah commands either) from inside the toolbox.

$ podman start haproxy-test
WARN[0000] using rootless single mapping into the namespace. This might break some images. Check /etc/subuid and /etc/subgid for adding subids
Error: unable to start container “haproxy-test”: container create failed: container_linux.go:345: starting container process caused “process_linux.go:430: container init caused “rootfs_linux.go:58: mounting \“devpts\” to rootfs \”/home/navaati/.local/share/containers/storage/vfs/dir/c0f31ef1c2cbe407e81801ab5e9b7e86de343fa817747a6b26af44e07c2c2e3f\” at \"/home/navaati/.local/share/containers/storage/vfs/dir/c0f31ef1c2cbe407e81801ab5e9b7e86de343fa817747a6b26af44e07c2c2e3f/dev/pts\" caused \“invalid argument\”""
: internal libpod error

I realize I could just go out of the toolbox, start my container, and go back. Still… Do you think there could be a way to make it smoother ?

#2

Hmm I don’t think this would be possible. At least off the top of my head rootless podman uses fuse-overlayfs, but FUSE doesn’t work inside namespaces. Not quite sure how it would go if switching to the VFS backend, but glancing at the error it still might not work…

#3

Mmh, I was thinking about a less “recursive” solution, such as escaping to the host for launching containers.

Now that I’m thinking about it podman doesn’t work but Docker, with its daemon approach, would probably work… But don’t tell Dan Walsh :wink: !

#4

Ah for this you can use the varlink api, as long as you pass the varlink socket into the container (whether the api was started via systemd or podman varlink) it should work.

#5

This Github issue talks about running Podman from toolbox:

Quote from the issue: “You’d need toolbox Git master for this to work best.”

Disclaimer: I have not tried toolbox myself.