Clarify platform requirements for 1.86 release #201129
Comments
|
Can you please share your remote SSH logs?
|
|
Sure here goes: [17:08:01.616] Using SSH config file "C:\Users\roy000.ssh\config"
[17:08:03.993] Remote server is listening on port 38035 [17:08:04.267] [server] Checking /home/royd/.vscode-server-insiders/cli/servers/Insiders-279872bd965e4030c81129a9bf1ce1710ff7cd55/log.txt and /home/royd/.vscode-server-insiders/cli/servers/Insiders-279872bd965e4030c81129a9bf1ce1710ff7cd55/pid.txt for a running server... [17:08:04.779] SSH Resolver called for "ssh-remote+hpc2.cc.uit.no", attempt 2, (Reconnection) [17:08:05.019] Using SSH config file "C:\Users\roy000.ssh\config"
[17:08:06.465] Remote server is listening on port 45001 [17:08:06.630] ------ [17:08:06.630] SSH Resolver called for "ssh-remote+hpc2.cc.uit.no", attempt 3, (Reconnection) [17:08:07.043] Using SSH config file "C:\Users\roy000.ssh\config"
[17:08:08.113] Remote server is listening on port 44167 [17:08:08.260] ------ [17:08:08.260] SSH Resolver called for "ssh-remote+hpc2.cc.uit.no", attempt 4, (Reconnection) [17:08:08.516] Using SSH config file "C:\Users\roy000.ssh\config"
[17:08:10.906] Remote server is listening on port 46486 [17:08:11.079] ------ [17:08:11.079] SSH Resolver called for "ssh-remote+hpc2.cc.uit.no", attempt 5, (Reconnection) [17:08:11.530] Using SSH config file "C:\Users\roy000.ssh\config"
[17:08:13.923] Remote server is listening on port 37004 [17:08:14.596] [server] [17:08:14] [Error: ENOENT: no such file or directory, scandir '/home/royd/.vscode-server-insiders/data/logs'] { |
|
Ahh, now that I know where to look it appears that the libstdc++ on CentOS is too old for the Node version used in Insiders. From the log: I guess I should upgrade my jumphost. Was planning to do that anyway, but there are still a bunch of CentOS7 servers around so you should be prepared for a lot of complaints when this hits regular VSCode. |
|
This happened in microsoft/vscode-linux-build-agent#43, will confirm what the new versions of everything are so we can update our checkers which would normally give you a nicer alert |
connor4312
added
important
|
After the latest update, I'm still getting the same errors. |
|
Confirmed no terminal launching on update: |
|
Diving into this more, it looks like the breaking change is the new requirement of Related breaking change: microsoft/vscode-linux-build-agent#41 Related article: https://repost.aws/questions/QUrXOioL46RcCnFGyELJWKLw/glibc-2-27-on-amazon-linux-2#ANEsMHX3NuRr682Bn6t0z5gw |
vscodenpa
added
the
unreleased
|
Can someone explain why this issue is closed if my terminal still wont launch? |
|
They upped the minimum requirements. Looks like it's not supported anymore. |
Me,too |
|
I guess I won't be able to use Ubuntu 18 WSL anymore? |
|
TBD whether Ubuntu 18 and such will be supported for the next release; we're still evaluating:
|
|
We will share additional details on the GLIBC version bump after the holidays but the gist is that we are aligning our platform requirements to be same as Node.js v18 that is used for our server binaries. Newer requirements will be GLIBC >= 2.28 and GLIBCXX >= 3.4.25 moving forward. |
deepak1556
changed the title
|
A workaround is to sideload a newer version of the needed libraries into a non-system location. For instance using conda to install nodejs will pull inn libgcc-ng and libstdcxx-ng. Then putting export LD_LIBRARY_PATH=$HOME/myenv/lib:$LD_LIBRARY_PATH into .bashrc makes the remote server work again. (that is, the embedded terminal doesn't seem to work). (~/myenv is the location of my own conda environment). |
|
If this is really going to be done a useful addition would be to allow the remote extension to search for GLIBC in a non-standard, VSCode-configurable location. In CentOS 7 one could install GLIBC 2.28+ in a non-standard location (which is not totally painless) but I would not want to set |
|
I guess there are some ways to resolve this problem such as supporting old version remote server by plugin and static complie remote server? |
|
I upgraded from Ubuntu 18 to 22 in order to get around this problem but I'm now realizing I won't be able to use Code on my university's computing cluster (RHEL7)...this is truly a painful change. I agree that facilitating support for GLIBC in a non-standard location would soften the blow. Or even optionally bundling the needed version of GLIBC? |
|
I totally see the point of using "official" node.js binaries, especially about not using a self-patched version - but has someone from the team considered to just switch to the "official unofficial" binaries (there are some for risc, armv61 longaarch, ...)? While it is explicit marked as experimental and comes with no guarantees - it actually works quite fine. From node.js 18.6 on there is a new one: x86_64-glibc-217 and of course it works fine. For upcoming electron releases and updated node.js dependency, they can also be used (the newest one is the 21.5 from December 2023). If this isn't used in the build pipeline (I'd highly suggest to do that as then it will just work for the users as before - get electron upstream, then replace node by the official unofficial glibc-217 one), then it is still usable, but with a one-time manual work as follows (the details may be a bit different as I don't use the MS builds, but it should work the same). Of course: check the node.js version in the about menu of vscode first, then check for the URL at https://unofficial-builds.nodejs.org/download/release that matches that minor version (taking the newest patchlevel, of course), if it isn't available, then use the one that comes after - 18.6 is the first one. Steps for the manual fix for remote workspaces (should also work fine with Amazon Linux - it would be nice if someone could check):
$ ls -lt ~/.vscod*-server*/bin/* # get the server version hash
$ VSC_BIN=~/.vscode-server*/bin/08e6c15293922dd53a864bb041be381322fee401 # use the directory/hash seen above
$ $VSC_BIN/node --version # executable found but execution fails
$ ldd -v $VSC_BIN/node # some details showing the broken glibc version
$ cd /tmp
$ wget https://unofficial-builds.nodejs.org/download/release/v18.16.1/node-v18.16.1-linux-x64-glibc-217.tar.xz
$ tar -xvf node-v18.16.1-linux-x64-glibc-217.tar.xz
$ cp -p node-v18.16.1-linux-x64-glibc-217/bin/* $VSC_BIN/
$ $VSC_BIN/node --version # runs
$ ldd -v $VSC_BIN/node # some details showing the working glibc version
$ cp -pr node-v18.16.1-linux-x64-glibc-217/lib/node_modules $VSC_BIN/ # this may be unnecessaryThe resulting server part can even be copied to other machines including RHEL9 and works fine out of the box. |
|
I tried to make it running on rhel 7 by pointing the correct env variables to a compatible glibc version. The only major thing not working as far as I can tell is the terminal. I suspect the node bootstrap to spawn new processes, not inheriting from the environment. There must be a simple fix for this, but my limited knowledge on node ends there. EDIT: Before the above-mentioned there is also this error. I've noticed that PS: Even if those systems are rather old (10 years in rhel 7 case) and going out of support, they still represent a big marketshare when it comes to enterprise infrastructures (which are all in on stability). |
vscodenpa
added
unreleased
This comment was marked as spam.
This comment was marked as spam.
I've tried these steps, and it does create a working $VSC_BIN/node --version returned, but it doesn't fix anything for letting vscode connect to the centos7 host. however, an easier work around for now is to change the default setting in vscode to update to the latest release (switch off) and install the november release (1_85) which still works with CentOS 7. |
|
Quote from @isidorn in #203375
The official working solution is to be posted there "when available". In the meantime you'd need to additional adjust the new version check script: https://github.com/microsoft/vscode/blob/main/resources/server/bin/helpers/check-requirements-linux.sh on the server, before trying to connect. |
|
I don't understand the answer. |
Type: Bug
Try to open a remote connection to an external linux server. It fails in recent VSCode Insiders. (Problem appeared sometime last week approximately) It works correctly in regular VSCode towards the same server.
Server OS: CentOS7
No rush, using regular VSCode until a fix arrives...
VS Code version: Code - Insiders 1.86.0-insider (279872b, 2023-12-18T05:36:59.983Z)
OS version: Windows_NT x64 10.0.22621
Modes:
Connection to 'SSH: hpc2.cc.uit.no' could not be established Refused to connect to unsupported server
Connection to 'SSH: hpc2' could not be established Refused to connect to unsupported server
System Info
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: enabled
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: enabled
Connection to 'SSH: hpc2.cc.uit.no' could not be established Refused to connect to unsupported server
Connection to 'SSH: hpc2' could not be established Refused to connect to unsupported server
A/B Experiments
The text was updated successfully, but these errors were encountered: