How to connect local VSCode instance to VS Code HA Add-on via ssh?

Third party integrations
17

i found more log in vscode console

17:06:05.952] > Waiting for server log...
[17:06:05.984] > Waiting for server log...
[17:06:06.016] >  
> *
> * Visual Studio Code Server
> *
> * By using the software, you agree to
> * the Visual Studio Code Server License Terms (https://aka.ms/vscode-server-license) and
> * the Microsoft Privacy Statement (https://privacy.microsoft.com/en-US/privacystatement).
> *
>  
[17:06:06.018] > Server did not start successfully. Full server log at /root/.vscode-server/.05047486b6df5eb8d44b2ecd70ea3bdf775fd937.log >>>
> musl libc (x86_64)
> Version 1.2.4
> Dynamic Program Loader
> Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname
> Warning: musl detected, skipping GLIBC check
> Error relocating /root/.vscode-server/bin/05047486b6df5eb8d44b2ecd70ea3bdf775fd937/node: fcntl64: symbol not found
> <<< End of server log
18

Hello, I’m facing exactly the same issue described by @xiduis15.
The issue appeared this afternoon.
I’ve been using heavily my local VS Code connecting to VS Code HA add-on via SSH, for several weeks without any issue before this afternoon.
I updated HA from 2024.1.5 to 2024.1.6 today.
I also remember clicking on a message proposing to update VS Code today.
I’m now facing the same issue described by @xiduis15.
VS Code add-on within HA works perfectly.
Advanced SSH & Web Terminal also works.
I did a full restart of HA using the option “Reboot system: Restarts the system running Home Assistant and all add-ons”. Still facing the issue.
Current configuration:

  • HA 2024.1.6.
  • Studio Code Server add-on 5.15.0.
  • Advanced SSH & Web Terminal add-on 17.0.4.
  • VS Code desktop: Version: 1.86.0 / Commit: 05047486b6df5eb8d44b2ecd70ea3bdf775fd937

Thanks for any help.

19

Hello, FYI the issue seems to be on VS Code’s side with the 1.86.0 update.

I’ve found several issues describing the same problem on VS Code’s GitHub.
See for example:

EDIT: I found the exact description of the issue here:

Watching this specific issue will let us know when it’s resolved.

For the moment the solution seems to be to downgrade VS Code to 1.85.2.
I haven’t yet tried the downgrade so can’t comment further.

20

Happy to report that I’ve solved the issue by:

  1. Launching my VS Code desktop version 1.86.0.
  2. Downgrading the remote-ssh extension version to 0.107 from within VS Code.
  3. Changing the ‘update mode’ setting to ‘none’ (will require a restart of VS Code).
  4. Downloading and installing version 1.85.2 of vscode.

After following these steps, I’m now able to connect my desktop VS Code (1.85.2) to VS Code HA add-on via SSH, as I used to previously.

The underlying issue remains however: a dependency on some libraries on HA add-on’s side (minimum GLIBC >= 2.28 apparently from the comments in the GitHub issues) is preventing VS Code 1.86.0 from connecting successfully over SSH.
Hoping this issue will be fixed soon…

4 Likes
21

amazing, @eugene78 ! Thanks for all the follow ups :slight_smile:

22

Nice, can confirm that downgrading the versions gets it working again. I took a look at the github issues and currently they’re not planning to fix it but may have misjudged how widely used it is. Luckily someone developed a workaround script for the latest versions as well. First you’ll need to add some more packages to the SSH addon:

  • nodejs
  • npm
  • make
  • g++

With those installed, save the script in one of the mounted directories like /root/share, otherwise you’ll lose it when the container restarts. All I changed was the mynode variable to /usr/bin/node. After running the script to install the npm dependencies, remote ssh with vscode 1.86 is back in business.

Even better - the new versions allow you to silence that notification about not meeting all the prerequisites.

23

Thx a lot @eugene78 ! it’s work great for me

24

Guys… Drop SSH and use this integration:

It fires up a Remote Tunnel (not Remote SSH) to connect to from your vscode or vscode.dev using your Github credentials. Works perfect! You do need to enable it after every HA restart… but hey… we’ve got automations for that :blush:

Some extra information:
Vscode Remote Tunnels

25

Interesting… the downside being that has to bounce through Azure instead of staying on the same LAN

26

I too just ran into this issue, but I’m a bit green on doing command line stuff.

I can access root/share through HA File editor addon and create the file, can you tell me how to run it?

Given that we want this file not to be deleted, I assume we have to rerun it every reboot, or can that be automated?

27

The install goes to /root/.vscode-server, so that should stick around while you’re using the same container including after rebooting. I think the only time you’d need to re-run it is after upgrades to the SSH addon.

Looking again now, the easiest way to run it is probably to add it to the init_commands of the addon:

/bin/bash /root/share/vscodefix.sh

On my system that still takes about a minute to run after it’s already installed, so give it some time for npm to do its thing.

28

That didn’t seem to work for me. Had to swap to YAML mode config as packages were failing to save and there was no field for init_commands but I think I have it right.

I can’t seem to spot anything interesting/related to the script in the addon logs either.

How would I go about just running this script manually for now, just throw it into the addons terminal?

Rebooted HA and VSCode seems to be up and running now. Cheers for the help!

1 Like
29

Hello, could you help me understand how using this integration would help solve the libraries issues?

The diagram on the VS Code Remote Tunnels page shows VS Code server running on the remote environment, which in my case would be my HA OS installation (installed in a VM on Proxmox).

How/why would this situation be different & better than my current configuration using the Advanced SSH & Web Terminal add-on?

Thanks for your clarifications.

30

It’s just easy to set up and it works with vscode.dev too (browser app / PWA). I’m not trying to sell it, just telling it’s working great and doesn’t require you to set up SSH access…

31

Happy to report that VS Code 1.86.1 update that was released on Feb. 8th has solved the issue, enabling again to connect to HA instance over SSH.

How to install the upgrade:

  1. Launch VS Code desktop version 1.85.2.
  2. Go to Settings and change the “update mode” setting back to ‘default’. This will require a restart of VS Code.
  3. After restarting VS Code, execute Code / Check for updates… (on Mac). This will download the 1.86.1 version and prompt another restart.
  4. After restarting again, the “Remote - SSH” extension should prompt an update to version 0.108.0. Be sure to select “auto-update” for this extension.

Note Microsoft’s position here:

We have discussed this more in the VS Code team and we have decided to allow VS Code to connect to an OS that is not supported by VS Code (no support for glibc >= 2.28) for 12 more months .
We hope this will provide the needed time for you and your companies to migrate to newer Linux distributions.

So while the issue is solved in the short term, we still need a proper solution for the longer term.

Cheers!

1 Like
32

I recently tried to use the SSH extension as well with the latest VSCode and and latest HA updates. The VSCode remote Server seems to need a real ps command and not the alpine shipped busybox variant.
If anyone faces some issues and sees a ps related error in the log try adding the package procps to the packages section of the ssh and terminal extension.
This made it work for me.

5 Likes
33

Nice, procps fixed mine again too for 1.88

34

Amazing, thanks so much. I was noticing ps was failing but didn’t realize it was busybox being the issue.

35

Yass! Nice catch! I wasn’t able to catch that in the ssh output while trying to connect. Thanks!

36

Same for me, the procps was the solution, full working config:

ssh:
  username: my_user
  password: ""
  authorized_keys:
    - my_key
  sftp: false
  compatibility_mode: false
  allow_agent_forwarding: false
  allow_remote_port_forwarding: true
  allow_tcp_forwarding: true
zsh: true
share_sessions: false
packages:
  - procps
init_commands: []