Toolbox on Silverblue does not work after su -l login - is it really true?

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.
1 Like

If you read the pasted commands, @paintitblack is actually using sudo su -l Jack-developer

1 Like

This issue "Error: host directory cannot be empty" when running "toolbox create" as non-root user ¡ Issue #886 ¡ containers/toolbox ¡ GitHub is not strictly related, but read the last comment:

export XDG_RUNTIME_DIR="/tmp/.xdg/${UID}"
mkdir -p $XDG_RUNTIME_DIR

Try to add -v or -vv

@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-24T11:55:51Z[]
Jack-developer@beast§/var/user_data/Jack-developer§
> whoami
Jack-developer

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).

Please don’t create duplicate topics.

Ref.

Here is a summary without all the noise.

> 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

Scott,

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.

1 Like

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?