Each project build has it own user, this assures that a build gone wrong does not affect files across projects. It has been setup this way for a long time and it is not an option to change this.
As shown below, after doing su -l into a project, toolbox create and toolbox enter do not work. There is a work around for the toolbox create problem as shown, but then toolbox enter does not work.
It would be nice to be able to easily install project specific tools on Silverblue, so any general solution, or workarounds for the entry problem would be much appreciated.
⌠this seems to be related to systemd. Is it possible to do a version of su -l that would also share the desktop, where toolbox would work?
2023-09-24T11:45:36Z[]
Jack@beast§/var/user_data/Jack§
> sudo su -l Jack-developer
[sudo] password for Jack:
Welcome to Fedora Linux 38.20230914.0 (Silverblue).
This terminal is running on the host system. You may want to try
out the Toolbox for a directly mutable environment that allows
package installation with DNF.
For more information, see the e]8;;https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/e\documentatione]8;;e\.
2023-09-24T11:46:13Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox list
IMAGE ID IMAGE NAME CREATED
bfe872bb72c1 registry.fedoraproject.org/fedora-toolbox:38 4 weeks ago
2023-09-24T11:46:23Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox create toolbox_name
Error: failed to create container toolbox_name
2023-09-24T11:46:45Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> export XDG_RUNTIME_DIR="/tmp/.xdg/${UID}"
2023-09-24T11:46:55Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox create toolbox_name
Created container: toolbox_name
Enter with: toolbox enter toolbox_name
2023-09-24T11:46:59Z[]
2023-09-24T11:47:10Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox list
IMAGE ID IMAGE NAME CREATED
bfe872bb72c1 registry.fedoraproject.org/fedora-toolbox:38 4 weeks ago
CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME
b334f0073baf toolbox_name 8 minutes ago running registry.fedoraproject.org/fedora-toolbox:38
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox enter toolbox_name
Error: failed to inspect entry point of container toolbox_name
2023-09-24T11:47:10Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox list
IMAGE ID IMAGE NAME CREATED
bfe872bb72c1 registry.fedoraproject.org/fedora-toolbox:38 4 weeks ago
CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME
b334f0073baf toolbox_name 8 minutes ago running registry.fedoraproject.org/fedora-toolbox:38
With su -l you are root. Toolbox is a rootless container. This means if you want to make different users, you have to use su differentuser -l to login and work with this explicit user. And by the way if you read the toolbox info, you will see that it is for command line tools.
If you want to call the toolbox terminal from a specific user (Desktop), you will have to make a .desktop file who opens a terminal for the specific user ⌠it could look like this way:
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Icon=mate-panel-launcher
Icon[en_US]=gnome-launcher
Name[en_US]=Your terminal app name
Exec=gnome-terminal --geometry=112x24+600 --window -e /home/$USERNAME/bin/helperscript
Comment[en_US]=Comment for your helperscript
Name=helperscript
the helper-script could look this way:
#!/bin/bash
su myproject-username -l
# add whatever commands you like to use, to automate your workflow.
@alciregi is correct, the -l can go before the username, and if you look on that command line, the username is specified. The sudo before it assures that the su -l will not ask for a password is all. This was typed in the same shell shown in the original post as the next command:
2023-09-24T14:53:13Z[]
Jack-developer@Sunshine§/var/user_data/Jack-developer§
> echo $XDG_RUNTIME_DIR
/tmp/.xdg/2005
2023-09-24T15:00:45Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> ls /tmp/.xdg/2005
. .. containers crun libpod toolbox
2023-09-24T15:00:53Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox list
IMAGE ID IMAGE NAME CREATED
bfe872bb72c1 registry.fedoraproject.org/fedora-toolbox:38 4 weeks ago
CONTAINER ID CONTAINER NAME CREATED STATUS IMAGE NAME
b334f0073baf toolbox_name 3 hours ago running registry.fedoraproject.org/fedora-toolbox:38
2023-09-24T15:01:15Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> toolbox -v enter toolbox_name
DEBU Running as real user ID 2005
DEBU Resolved absolute path to the executable as /usr/bin/toolbox
DEBU Running on a cgroups v2 host
DEBU Looking for sub-GID and sub-UID ranges for user Jack-developer
DEBU TOOLBOX_PATH is /usr/bin/toolbox
DEBU Migrating to newer Podman
DEBU Toolbox config directory is /var/home/Jack-developer/.config/toolbox
DEBU Current Podman version is 4.6.2
DEBU Creating runtime directory /tmp/.xdg/2005/toolbox
DEBU Old Podman version is 4.6.2
DEBU Migration not needed: Podman version 4.6.2 is unchanged
DEBU Setting up configuration
DEBU Setting up configuration: file /var/home/Jack-developer/.config/containers/toolbox.conf not found
DEBU Resolving container and image names
DEBU Container: ''
DEBU Distribution (CLI): ''
DEBU Image (CLI): ''
DEBU Release (CLI): ''
DEBU Resolved container and image names
DEBU Container: 'fedora-toolbox-38'
DEBU Image: 'fedora-toolbox:38'
DEBU Release: '38'
DEBU Resolving container and image names
DEBU Container: 'toolbox_name'
DEBU Distribution (CLI): ''
DEBU Image (CLI): ''
DEBU Release (CLI): ''
DEBU Resolved container and image names
DEBU Container: 'toolbox_name'
DEBU Image: 'fedora-toolbox:38'
DEBU Release: '38'
DEBU Checking if container toolbox_name exists
DEBU Inspecting mounts of container toolbox_name
Error: could not find any cgroup in "/proc/253417/cgroup"
Error: failed to inspect entry point of container toolbox_name
2023-09-24T15:01:23Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> cat /proc/253417/cgroup
0::/user.slice/user-2000.slice/user@2000.service/app.slice/dbus-:1.2-org.gnome.Nautilus@1.service
What is a cgroup, and why is it not finding it? With -vv the output is quite long, let me know if you would like to see it. This looks to be the interesting part:
DEBU[0000] Initializing event backend journald
DEBU[0000] Configured OCI runtime runc initialization failed: no valid executable found for OCI runtime runc: invalid argument
DEBU[0000] Configured OCI runtime kata initialization failed: no valid executable found for OCI runtime kata: invalid argument
DEBU[0000] Configured OCI runtime youki initialization failed: no valid executable found for OCI runtime youki: invalid argument
DEBU[0000] Configured OCI runtime krun initialization failed: no valid executable found for OCI runtime krun: invalid argument
DEBU[0000] Configured OCI runtime crun-wasm initialization failed: no valid executable found for OCI runtime crun-wasm: invalid argument
DEBU[0000] Configured OCI runtime runj initialization failed: no valid executable found for OCI runtime runj: invalid argument
DEBU[0000] Configured OCI runtime runsc initialization failed: no valid executable found for OCI runtime runsc: invalid argument
DEBU[0000] Configured OCI runtime ocijail initialization failed: no valid executable found for OCI runtime ocijail: invalid argument
DEBU[0000] Using OCI runtime "/usr/bin/crun"
WARN[0000] The cgroupv2 manager is set to systemd but there is no systemd user session available
WARN[0000] For using systemd, you may need to log in using a user session
WARN[0000] Alternatively, you can enable lingering with: `loginctl enable-linger 2005` (possibly as root)
WARN[0000] Falling back to --cgroup-manager=cgroupfs
INFO[0000] Setting parallel job count to 49
DEBU[0000] Failed to add podman to systemd sandbox cgroup: dial unix /run/user/0/bus: connect: permission denied
DEBU[0000] Error parsing cgroup: expected 3 fields but got 4: /proc/253417/cgroup
Error: could not find any cgroup in "/proc/253417/cgroup"
DEBU[0000] Shutting down engines
Error: failed to inspect entry point of container toolbox_name
The âyou might need to log in using a user sessionâ is the part that calls the question if toolbox will work with âsu -lâ. Though it does say (or intended to say) âmightâ. (note RFC2119).
> sudo su -l Jack-developer
[sudo] password for Jack:
Welcome to Fedora Linux 38.20230914.0 (Silverblue).
This terminal is running on the host system. You may want to try
out the Toolbox for a directly mutable environment that allows
package installation with DNF.
> toolbox create toolbox_name
Error: failed to create container toolbox_name
> export XDG_RUNTIME_DIR="/tmp/.xdg/${UID}"
> toolbox create toolbox_name
Created container: toolbox_name
Enter with: toolbox enter toolbox_name
> toolbox enter toolbox_name
Error: failed to inspect entry point of container toolbox_name
You have made a bit of mess. You closed the post with the âtoobox createâ question and pointed it at a post asking about âalternatives to toolboxâ. Those are not the same.
You closed the post asking about alternatives to toolbox, and pointed it at a post with the âtoolbox enterâ question. Those are not the same.
Before you closed the question about alternatives to toolbox, you posted a bunch of stuff off topic. When I pointed out that they were off topic, you closed the thread.
Now there is a second post asking for alternatives to toolbox, because you closed the first one asking about this.
Things could have been better with my posts. I apologize if you were confused by my showing the problem I had with toolbox as a reason for asking for alternatives. Though the title and the post do say it is asking for alternatives. I also apologize that I did not do a good job pointing the âtoolbox createâ question to the âtoolbox enterâ question that it lead to. Instead of changing the title I should have noted the âtoolbox enterâ problem that the proposed solution seemed to have turned the âtoolbox createâ problem into.
In any case, the current duplicate messages are inaccurate and confusing. If you want to combine the âtoolbox createâ and the âtoolbox enterâ discussions, then the article currently entitled âtoolbox create and enterâ should point to âtoolbox enterâ (or vice versa). The first âtoolbox alternativesâ question that you closed, can not point anywere as you included a discussion of the âtooblbox enterâ problem in it, instead of discussiong alternatives. You could delete your off topic replies, I could modify the post text, and then you could point it at the other âtoobox altternativesâ perhaps.
Maybe itâs worth taking a step back to consider what you want to achieve and whether sudo su -l projectuser followed by toolbox is the proper means to achieve that. (sudo su rings a warning bell to some of us already.)
You want to separate project development per project. Toolboxâs mains aim is to separate the âsoftware environmentsâ: overly simply speaking, it gives you separate /usr per toolbox (plus âŚ) but no separate /home. This is ideal for isolating package dependencies etc without needing root, because your ordinary user âisâ root within the toolbox container. No su priviledges required.
Note that the (your) ordinary user in the toobox has full access to your /home/youruser.
The fact that you create separate project users indicates that you actually want to have separate home directories. Toolbox cannot do that, itâs aim is different.
Are you using toolbox to have project user specific software environments, and the different users to separate their homes? You may want to try out distrobox then, which basically forked off an early toolbox and provides the option to set a specific homedir per toolbox/distrobox container. That is, you can add restrictions compared to the default toolbox setup.
But maybe want to come from the other direction instead - set up a podman container (which is what those boxes are) and add the permissions and access that you need. Or do the environments differently, itâs hard to tell what you are using the toolbox for.
Hello Michael, I started another thread to discuss workflows, Alternatives to Toolbox? There is a post there with a list of articles posted by people with similar issues. I do not see this as a workflow problem, though I look forward to seeing your thoughts on workflows on the thread for that topic.
It is completely reasonable to expect the container to work after a person logs in, independent of how that login was accomplished. It is unwise to make su -l a second class citizen, in my humble opinion. Nor do I see a grand discussion among linux developers about making su -l logins second class citizens. And the current behavior has indeed surprised a number of people, as evidenced by the multiple posts about it.
It seems some people found a workaround by setting an environment variable, but as you can see here, that did not work here. Perhaps a version issue? Perhaps someone knows how to make this work? That is the question here. How can this be made to work?