How to properly set up VSCode and toolbox containers?

Ask Fedora
1

I decided to try Kinoite, but I have tried following every guide there is, but none fully sets up a proper dev environment on my machine.

My current setup:

  • VSCode in rpm-ostree.
  • A toolbox fully set up for development, I’ve verified that I can compile and run a project from command line.
  • A project that uses GLFW and requires graphics access.

My goal:

  • Allow vscode to connect to the toolbox.
  • Auto-connect to a non-root user.
  • GUI works.
  • Preferrably, I don’t have to setup everything again when I open a new workspace.

However, vscode never completely behaves right. I tried the following:

  • Open the project folder directly and toolbox enter from terminal. I can build it, but none of the linting/LSP work.
  • Install code inside container and launch, and vscode cannot connect to host system service.
  • Connect vscode to the toolbox container via Dev Containers, but it auto log ins as root, and I cannot figure out how to prevent that.
  • I followed this with the magic config file, and I can log in as my user, the project cannot launch because it has trouble creating a window.

Atomic OS is interesting, but is it just not designed for IDEs?

2

On this one, have you tried using DevContainers and specifying the relevant VSCode extensions in the devcontainer.json ?

For example, for basic Python support you might add:

	"customizations": {
		"vscode": {
			"extensions": [
				"ms-python.python",
				"ms-python.vscode-pylance"
			],
		}
	},
3

There isn’t one generated. I was opening the toolbox from the Dev Containers sidebar then opening the folder. I’ve never used dev containers before, it’s mostly Atomic Desktop forcing me to use them (without a manual).

4

Ah, I meant the JSON file referred to here (your “magic config file”).

Looks like the filename isn’t literally devcontainer.json, but it appears to serve the same function.

5

That one allows me to enter as my user instead of root. However, GLFW cannot initialize in that environment, and thus my project can’t run. An additional (smaller) problem is that I have to write that magic config file for every new workspace I create for that toolbox.

6

Right, I was responding specifically to your first point, about the lack of linting etc.

I suspect the problem creating a window might be that the Wayland socket from the toolbx isn’t properly forwarded to the host, but not sure why that doesn’t work here. Perhaps you want to post some logs of the error, and others may have some ideas.

7

What kind of logs? If you are talking about my application, it’s just GLFW can’t initialize:

WARNING: GLFW: Error: 65550 Description: X11: Failed to open display :0
WARNING: GLFW: Failed to initialize GLFW
WARNING: SYSTEM: Failed to initialize platform

Despite the DISPLAY variable being passed by the magic config.

8

OK, so it’s trying to open an X11 session.

I don’t use Toolbox, but I have done something a bit similar, developing an app in an Ubuntu-based Podman container that created X11 windows.

I found I needed these in my devcontainer.json:

	"mounts": 	        ["source=/tmp/.X11-unix,target=/tmp/.X11-unix,type=bind,ro",
					     "source=${localEnv:XAUTHORITY},target=/home/containeruser/.Xauthority,type=bind,ro"
				        ],

	"containerEnv": {	"DISPLAY":		"${localEnv:DISPLAY}",
					    "XAUTHORITY": 	"/home/containeruser/.Xauthority"},

    "runArgs": 	["--security-opt=label=type:container_runtime_t"],

where containeruser is the name of the user that the app runs as inside the container.

I could successfully connect to the container from VSCode and create windows (which showed on the host system as XWayland windows).

But I don’t know if that is exactly what you need, or if Toolbox containers have extra nuances.

9

Just in case, you can give distrobox a try. It’s based on toolbox and is available in the Fedora repo. It supports the VSCode Flatpak and inside distrobox installation (But NOT native installation). You can connect VSCode flatpak to a distrobox using Dev Containers and the developer provides a guide/script that manages environment variables and solves the issue mentioned above.

1 Like
10

None of these work.

11

Distrobox doesn’t even start. I waited several minutes and it’s still hanging.

12

Could you share more details? I just created a new one, and everything looks fine on my end.

$ distrobox create --image registry.fedoraproject.org/fedora-toolbox:42 --name test
Creating 'test' using image registry.fedoraproject.org/fedora-toolbox:42         [ OK ]
Distrobox 'test' successfully created.
To enter, run:

distrobox enter test


$ distrobox enter test
Starting container...                            [ OK ]
Installing basic packages...                     [ OK ]
Setting up devpts mounts...                      [ OK ]
Setting up read-only mounts...                   [ OK ]
Setting up read-write mounts...                  [ OK ]
Setting up host's sockets integration...         [ OK ]
Integrating host's themes, icons, fonts...       [ OK ]
Setting up distrobox profile...                  [ OK ]
Setting up sudo...                               [ OK ]
Setting up kerberos integration...               [ OK ]
Setting up user's group list...                  [ OK ]
Setting up existing user...                      [ OK ]
Ensuring user's access...                        [ OK ]

Container Setup Complete!
fish: Unknown command: bat
~/.config/fish/config.fish (line 5): 
        bat -pp $todo
        ^~^
from sourcing file ~/.config/fish/config.fish
        called during startup

$
13

That works. However, when I attach with vscode, I am still connected as root.

14

Did you check the VSCode integration guide? I remember it doesn’t work well if VSCode is installed natively with rpm-ostree. You can either install VSCode inside the distrobox or install the VSCode Flatpak and follow the setup here:

15

The flathub version doesn’t even have a proper terminal shell, which is why I didn’t use it. I tried just now with the guide, and it can’t find any containers running on my system.

16

Now when I try to attach to the distrobox container (from rpm-ostree code), it’s either:

  • Attached as root, which I don’t want
  • Attached to a different container, installed by toolbox
  • Use the distrobox provided podman-host script, and crash
17

Yes, the Flatpak version does not have access to the host system’s terminal shell. But if you’re doing development inside the container, you usually only need access to the container’s terminal shell.

In the worst case, you can just install everything on the host system using rpm-ostree. Sorry, I can’t help much further.

18

Is it VScode or Vscodeium?
the original VScode comes with all the telemetry etc.

I managed to install Vscodeium in a toolbox container (in fact, i created a separate one for dev tools) and it run perfectly fine out of it even in fedora 42 a year ago, I don’t remember any issues. However now I use the flatpak version (from Flathub). Is there a reason you want to run it out of a container, or perhaps the flathub version could be easier?

For example, you could configure container port pass-through and ssh from the flatpak vscode into the container as you normally would into a remote server?

19

I am starting with the original vscode. I know there are telemetry, I just need to make sure my setup works before trying other versions.

For reason why I need non-flatpak vscode: I need vscode to work with my host system because I use it more than for containerized software development. I don’t want to use the sh shell inside flatpak when I am not working with a container with no autocomplete.

I can try ssh into the container.

20

SSH doesn’t work either. VSCode can’t create the server installation directory.