After installing vscode inside distrobox-universal, devmode vscode stopped working

Bluefin and Aurora
1

So, I installed vscode inside distrobox-universal, just to see what happens, and it just worked correctly.
But after that normal vscode that comes with the devmode is just stopped working. When i try to open it, it says “The window terminated unexpectedly (reason: ‘crashed’, code: ‘133’)”. I tried uninstalling vscode from the distrobox and deleting ~/.vscode and ~/.config/Code still the same issue.
Now vscode only works if i install it inside distrobox and start it from there.

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx-nvidia:gts
                   Digest: sha256:c4ccf45ab7eaafce287b91bdd1f536281e1081536ed2ddce8e4cb7ee002eb108
                  Version: 38.20240204.0 (2024-02-05T02:59:12Z)

  ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-nvidia:gts
                   Digest: sha256:6d44105e7db43d2ad8cfe80313c6756c5f6e3a7b2e6f88d00f8951f93fc42bc6
                  Version: 38.20240204.0 (2024-02-05T02:34:17Z)
2

Me and another user had the same issue. Unfortunately I don’t know any solutions. @arenas93 fixed it by restoring a snapshot with Rescuezilla, so that’s something to try if you use similar tools.

3

Disclaimer: I’m not on *nvidia*

But for me it started working —again— after rebasing Bluefin to latest (i.e. 39).

Though, different from Bluefin Administrators Guide on upgrading, I had to use

rpm-ostree rebase ostree-image-signed:docker://ghcr.io/ublue-os/bluefin-dx:latest

See also Jorge’s comment here on Rebasing Bluefin to latest.

hth

4

Oh those commands needed to be updated with that snippet, good eye! (Fixed it)

5

Unfortunately, didn’t help. But doing ujust update now maybe it will magically resolve it somehow. I will give an update once it’s done and I have time.

1 Like
6

I wonder if there’s some dotfile collision that happened?

7

Well that didn’t work. Gonna install and use distrobox vscode for now.
I will investigate more when I can.
But if anyone else has the solution or has any idea why is this happening, your input would be appreciated.

8

There is one more thing that I did: for resetting vscode I also removed rm ~/.local/share/ublue/vscode-configured followed by ujust update.

This is b/c the team slightly adopted the mechanics for the vscode installation between the ISO and latest. Actually the change is intended to allow for (future) versioned vscode installs. BUT by deleting this file you’ll kinda force a clean vscode install w/ extension.

9

Unfortunately again, didn’t help. Even tried to going back to gts then latest again. Still the same issue.
Also, code serve-web seem to work, only the window fails(crashes).

10

How about creating a new profile with --profile?

11

Same issue, i mean i deleted every vscode dir anyway.

I mean i would imagine if i reset everything about vscode, it should just work? Is there anything else about vscode in the system other than ~/.vscode, ~/.config/Code, ~/.local/share/ublue/vscode-configured.

Also just realized, after i deleted it last time vscode-configured didn’t appear again, after doing ujust update (never mind it turns out i deleted it again after last time, it appeared after reboot)

Anything more I can share like logs?

12

Works now after the last update.

Lesson learned:

Always use --home option to set a different home folder for your distrobox, I prefer doing --home "$HOME/Boxes/<container name>".
And you can link ~/.config/dconf inside the container to have correct theme and stuff inside the container.
This method also keeps the home folder clean.

13

Installing vscode inside a container is the opposite of what we recommend. :smile:

If you launch vscode and run a new devcontainer:

image
image930×163 14.4 KB

You can run the universal container directly from vscode.

image
image942×259 28.3 KB

14

Yup, I know, its just sometimes stuff in containers might “corrupt” the home folder its better having a different home folder for the container or containers.

i wasn’t trying to run the vscode from container to work in it anyway :slight_smile:
i just did it at that time:

But in general its good to have a different home directory, at least for what i expect from containers. What I expect is a clean host.

Complained about state of linux in general. Which is also an issue in other OS(s) too

That’s why I remove host or home access from flatpaks too. Flatpak file/dir open/save dialog already auto shares file/dir from host with the flatpak app.

And that’s why I am not doing the Brew way, instead I have a devbox-ubuntu and devbox-fedora distrobox(es) with their own home folders.
I don’t like having bunch of random (.) files or folders in the home directory, that idk if i can delete or not, idk what is using them, idk if anything needs them etc.
It seems linux is not gonna get away from using (.) files/dirs at home any time soon, so using sandboxes, containers or lying about the home path is the only way atm.
I’m just tolerating seeing .vscode, .config, .local, .var, .bash-history, .bash-profile, .nv, .pki, .ssh, .cache …

You could argue why do these “apps” able to claim random paths in my home folder without asking me. It feels like software has more power than the user, that you constantly have to monitor what they do, and clean behind them. Makes you feel less in control.
I hope we solve these in the future with better and more strict flatpak. Like on android, and it can be even better than that.

We have been treating software like they are user’s will, but we should treat them just like another user on the system.

15

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.