Change:
<ins> diff --git a/src/cmd/create.go b/src/cmd/create.go index 74e90b1..113ef80 100644 --- a/src/cmd/create.go +++ b/src/cmd/create.go @@ -423,6 +425,7 @@ func createContainer(container, image, release string, showCommandToEnter bool) "--volume", toolboxPathMountArg, "--volume", usrMountArg, "--volume", runtimeDirectoryMountArg, +		"--volume", "@glibc@:@glibc@:ro", }...) createArgs = append(createArgs, avahiSocketMount...) </ins>

Discussion:
Project description It's a tool to create pet-container using Podman. The container is fully mutable and maps your user home to the container. Metadata homepage URL: source URL: license: Apache-2.0 platforms: Linux
I took a brief look at this a couple of months ago after it was rewritten in go. I'll post what I had if I can find it. It uses meson/ninja as a build system which makes it kind of non-standard and a bit awkward to package compared to other go projects, might be easier to skip it and specify the build/install phases manually. IIRC it also needed completion/profile.d paths to be patched in, had issues trying to mount other paths on NixOS and it wanted flatpak for some reason.
I also took a shot at getting toolbox working a while back, and wrote a nix expression for building the package, but decided to try it out when podman is rolled out in a stable NixOS channel. Now that 20.09 is released, I'm trying it out but I get cryptic errors like the following: I might look into this further when I get the time, but people are welcome to look into this issue to try and fix it. Meanwhile, here's the nix expression to build it: Note that in order to use toolbox on NixOS, you seem to need the following config: People seem to be against usage of buildGoModule (see ), so if people are interested in seeing this in nixpkgs, someone probably needs to port this to buildGoPackage.
Hi , I modified a little your nix expression I a patch to check if exists (it not exists in my system for instance). I also changed to copy to and it's mapping this file inside the container. I'm having the same error. So I tried to start the container using podman, this way: Maybe the problem now is because o cgroups. I don't now.
I had to submit an upstream patch to fix an error introduced in newer builds with ownership of the toolboxRuntimeDirectory. I think this would be good to have, so I'm interested in carrying on the work. I was able to build toolbox (thanks for the derivation). The biggest issue seems to be this. Trying to start a container with yields: See this issue.

Seems that the reported issue occured when host and container glibc don't match. The toolbox binary gets bind-mounted into the fedora container, which may cause issues without the requisite store paths also being mounted. See: Toolbox is kinda leaky by design, so this might be a problem. <details<summaryContainer info </summaryWARN[0000] Error initializing configured OCI runtime kata: no valid executable found for OCI runtime kata: invalid argument DEBU[0000] using runtime "/nix/store/jkg2hzkxc2g05gsbpkb8sybh34j78syh-nvidia-podman/bin/nvidia-container-runtime" INFO[0000] Setting parallel job count to 73 DEBU[0000] Called inspect.PersistentPostRunE(/nix/store/h9was55f3ir6b2sq5vc96cpgns3qbfz0-podman-2.2.1/bin/podman --log-level debug inspect --format json --type container fedora-tool </details
I have it running! Hello from vim installed via dnf. It's blocked by my upstream patch which you can follow here: <img width="1278" alt="Screen Shot 2021-01-22 at 4 20 05 AM" src="https://user-"<img width="634" alt="Screen Shot 2021-01-22 at 4 21 13 AM" src="https://user-"
That's great I think toolbox is a great tool to have in NixOS.
Agreed! Please test the PR if you have time :) Thanks for your work!
Very happy to see your interest in Toolbox! I just wanted to point out that Toolbox doesn't actually need Flatpak proper. It's just the daemon which is a D-Bus session service that comes from but is completely separate from the rest of Flatpak. In fact, in Fedora, we ship it is a separate isolated sub-package. The purpose behind this daemon is to keep certain configuration files in the container's synchronized with their counterparts in the host. eg., , , etc.. Anyway, good news is that these days, since Toolbox 0.0.97, the daemon is no longer used for newly created containers, because the functionality has been absorbed into Toolbox itself.

One big reason was to enable rootful Toolbox containers (ie., ). Older, preexisting containers will continue to use the daemon, though.
Just a minor note. The actual issue is See the related for an explanation on how we solved it. Ideas for better solutions welcome. :)
I marked this as stale due to inactivity. &rarr;
This issue is important to me.
Any update on this? Can this be merged to upstream and closed?
Is there anything that you need from the Toolbx project?
There are two remaining roadblocks. To clarify, I no longer use nixos and will probably not work on this (I still am an active toolbox user, just on Fedora :)) glibc updates. Any time the hash of glibc changes in the nix store, all toolbox containers will break (and need to be recreated). I'm sure there is a clever way around this, either a service that runs after a nix-rebuild that updates the bind mounts, or patching toolbox to update the bind mount on each toolbox enter. These seem very nix (or guix) specific) SDDM issue, there's nothing I think toolbox should do about this. Nixpkgs could consider carrying the sddm patches until merged upstream. Anyone is free to takeover , I won't be continuing it. The PR "works" with the caveat of point 1 not being handled, so you'll have to periodically recreate toolboxes.
after the container creation, it's possible to change the bind mounts and ports? Is there a file to edit?
I found this alternative to toolbox
There's no support for doing it easily through a Toolbx-specific configuration file at the moment. However, you can script something through one of the shell start-up scripts.