search

microsoft / vscode-remote-release

Visual Studio Code Remote Development: Open any folder in WSL, in a Docker container, or on a remote machine using SSH and take advantage of VS Code's full feature set.
https://aka.ms/vscode-remote
Other
3.67k stars 292 forks source link

Can't connect to CentOS 7 ARM64 #2998

Closed LukeIreland1 closed 2 years ago

LukeIreland1 commented 4 years ago

Steps to Reproduce:

  1. Add the SSH command I use to connect to either machine, as prompted by VS Code.
  2. Connect to machine using VS Code Remote Development.

Does this issue occur when you try this locally?: Not sure I understand this question, but I can connect using a terminal via ssh just fine. Does this issue occur when you try this locally and all extensions are disabled?: I tried disabling all extensions and installing the Remote SSH extension when prompted upon reload with no good effect.

[14:41:11.887] Log Level: 2
[14:41:11.892] remote-ssh@0.51.0
[14:41:11.892] darwin x64
[14:41:11.899] SSH Resolver called for "ssh-remote+sabre-hpc-02.manchester.arm.com", attempt 1
[14:41:11.900] SSH Resolver called for host: sabre-hpc-02.manchester.arm.com
[14:41:11.900] Setting up SSH remote "sabre-hpc-02.manchester.arm.com"
[14:41:11.904] Acquiring local install lock: /var/folders/_h/0vvqtncn5v59nr0lx098lnyw0000gn/T/vscode-remote-ssh-sabre-hpc-02.manchester.arm.com-install.lock
[14:41:12.005] Looking for existing server data file at /Users/lukire01/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-sabre-hpc-02.manchester.arm.com-d69a79b73808559a91206d73d7717ff5f798f23c-0.51.0/data.json
[14:41:12.008] Using commit id "d69a79b73808559a91206d73d7717ff5f798f23c" and quality "stable" for server
[14:41:12.009] Install and start server if needed
[14:41:12.014] Checking ssh with "ssh -V"
[14:41:12.027] > OpenSSH_8.1p1, LibreSSL 2.7.3
[14:41:12.029] askpass server listening on /var/folders/_h/0vvqtncn5v59nr0lx098lnyw0000gn/T/vscode-ssh-askpass-fa14dc1239733b317d375d0746010478e1421959.sock
[14:41:12.029] Spawning local server with {"ipcHandlePath":"/var/folders/_h/0vvqtncn5v59nr0lx098lnyw0000gn/T/vscode-ssh-askpass-356e6d492a6ead4c2dcdf7b44a2f600b859d8eb7.sock","sshCommand":"ssh","sshArgs":["-v","-T","-D","60065","-o","ConnectTimeout=15","sabre-hpc-02.manchester.arm.com"],"dataFilePath":"/Users/lukire01/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-sabre-hpc-02.manchester.arm.com-d69a79b73808559a91206d73d7717ff5f798f23c-0.51.0/data.json"}
[14:41:12.029] Local server env: {"DISPLAY":"1","ELECTRON_RUN_AS_NODE":"1","SSH_ASKPASS":"/Users/lukire01/.vscode/extensions/ms-vscode-remote.remote-ssh-0.51.0/out/local-server/askpass.sh","VSCODE_SSH_ASKPASS_NODE":"/Applications/Visual Studio Code.app/Contents/Frameworks/Code Helper (Renderer).app/Contents/MacOS/Code Helper (Renderer)","VSCODE_SSH_ASKPASS_MAIN":"/Users/lukire01/.vscode/extensions/ms-vscode-remote.remote-ssh-0.51.0/out/askpass-main.js","VSCODE_SSH_ASKPASS_HANDLE":"/var/folders/_h/0vvqtncn5v59nr0lx098lnyw0000gn/T/vscode-ssh-askpass-fa14dc1239733b317d375d0746010478e1421959.sock"}
[14:41:12.035] Spawned 22305
[14:41:12.139] > local-server> Spawned ssh: 22306
[14:41:12.142] stderr> OpenSSH_8.1p1, LibreSSL 2.7.3
[14:41:12.290] > ready: 30d8fca23b1f
[14:41:12.317] > Linux 4.14.0-49.el7a.aarch64 #1 SMP Wed Mar 14 10:02:34 EDT 2018
[14:41:12.319] Platform: linux
[14:41:12.402] > 30d8fca23b1f: running
[14:41:12.451] > Acquiring lock on /home/lukire01/.vscode-server/bin/d69a79b73808559a91206d73d7717ff5f798f23c/vscode-remote-lock.lukire01.d69a79b73808559a91206d73d7717ff5f798f23c
[14:41:12.453] > \ln /home/lukire01/.vscode-server/bin/d69a79b73808559a91206d73d7717ff5f798f23c/vscode-remote-lock.lukire01.d69a79b73808559a91206d73d7717ff5f798f23c.target /home/lukire01/.vscode-server/bin/d69a79b73808559a91206d73d7717ff5f798f23c/vscode-remote-lock.lukire01.d69a79b73808559a91206d73d7717ff5f798f23c
[14:41:12.456] > Found existing installation at /home/lukire01/.vscode-server/bin/d69a79b73808559a91206d73d7717ff5f798f23c...
[14:41:12.542] > Found running server...
>  
> *
> * Reminder: You may only use this software with Visual Studio family products,
> * as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)
> *
[14:41:12.608] > Checking server status on port 35731 with wget
[14:41:12.609] > 30d8fca23b1f: start
> sshAuthSock====
[14:41:12.609] > agentPort==35731==
> osReleaseId==rhel==
[14:41:12.612] > arch==aarch64==
> webUiAccessToken====
[14:41:12.620] > tmpDir==/run/user/23964==
> platform==linux==
> 30d8fca23b1f: end
[14:41:12.631] Received install output: 
sshAuthSock====agentPort==35731==
osReleaseId==rhel==arch==aarch64==
webUiAccessToken====tmpDir==/run/user/23964==
platform==linux==

[14:41:12.632] Remote server is listening on port 35731
[14:41:12.633] Parsed server configuration: {"agentPort":35731,"osReleaseId":"rhel","arch":"aarch64","webUiAccessToken":"","sshAuthSock":"","tmpDir":"/run/user/23964","platform":"linux"}
[14:41:12.636] ** Note: Support for architecture "aarch64" is in preview **
[14:41:12.637] Persisting server connection details to /Users/lukire01/Library/Application Support/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-sabre-hpc-02.manchester.arm.com-d69a79b73808559a91206d73d7717ff5f798f23c-0.51.0/data.json
[14:41:12.641] Starting forwarding server. localPort 60067 -> socksPort 60065 -> remotePort 35731
[14:41:12.642] Forwarding server listening on 60067
[14:41:12.642] Waiting for ssh tunnel to be ready
[14:41:12.644] Tunneled remote port 35731 to local port 60067
[14:41:12.644] Resolved "ssh-remote+sabre-hpc-02.manchester.arm.com" to "127.0.0.1:60067"
[14:41:12.645] [Forwarding server 60067] Got connection 0
[14:41:12.657] ------

[14:41:12.703] [Forwarding server 60067] Got connection 1
[14:41:12.704] [Forwarding server 60067] Got connection 2
LukeIreland1 commented 4 years ago

Judging from the amount of new tickets unanswered, I imagine I'll be waiting a while for any help.

qianyizhang commented 4 years ago

I ran into the same problem, help wanted!

qianyizhang commented 4 years ago

as a workaround, and "re setup" ssh by following (again): https://code.visualstudio.com/docs/remote/troubleshooting#_installing-a-supported-ssh-client and removing .vscode-server on the server side completely. Then the connection works after some downloads.

LukeIreland1 commented 4 years ago

@qianyizhang Client-side is fine, as I can connect to another server just fine. Server-side has openssh-server installed, and sshd is enabled and started, and when I connected to the server, this verifies I'm using sshd.

I've tried deleting .vscode-server, each time is the same result of

Failed to connect to the remote extension host server (Error: Connection error: Unauthorized client refused.)

and

Could not fetch remote environment
BjBodner commented 4 years ago

I'm getting the same problem as @LukeIreland1, has this been resolved for you?

llabusch93 commented 4 years ago

+1 for me, any news on this?

krasznaa commented 4 years ago

I'm getting the same error. :frowning:

But one thing that nobody seems to have pointed out here is that I'm trying to connect to an aarch64 machine (that's running CentOS 7). Just as @LukeIreland1 seems to be.

For completeness, here is the full log that I get:

[14:31:14.615] Log Level: 2
[14:31:14.616] remote-ssh@0.55.0
[14:31:14.616] linux x64
[14:31:14.617] SSH Resolver called for "ssh-remote+thunderx2.cern.ch", attempt 1
[14:31:14.617] SSH Resolver called for host: thunderx2.cern.ch
[14:31:14.617] Setting up SSH remote "thunderx2.cern.ch"
[14:31:14.619] Acquiring local install lock: /tmp/vscode-remote-ssh-thunderx2.cern.ch-install.lock
[14:31:14.624] Looking for existing server data file at /home/krasznaa/.config/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-thunderx2.cern.ch-d2e414d9e4239a252d1ab117bd7067f125afd80a-0.55.0/data.json
[14:31:14.624] Using commit id "d2e414d9e4239a252d1ab117bd7067f125afd80a" and quality "stable" for server
[14:31:14.625] Install and start server if needed
[14:31:14.627] Checking ssh with "ssh -V"
[14:31:14.633] > OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020

[14:31:14.637] askpass server listening on /run/user/1000/snap.code/vscode-ssh-askpass-c6c8b6d3feab56fbab7b79e4a0a29fb16e78ab9f.sock
[14:31:14.637] Spawning local server with {"ipcHandlePath":"/run/user/1000/snap.code/vscode-ssh-askpass-fedec5f85802c36e2abae681e7584edf66e4ce84.sock","sshCommand":"ssh","sshArgs":["-v","-T","-D","37927","-o","ConnectTimeout=15","thunderx2.cern.ch"],"dataFilePath":"/home/krasznaa/.config/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-thunderx2.cern.ch-d2e414d9e4239a252d1ab117bd7067f125afd80a-0.55.0/data.json"}
[14:31:14.638] Local server env: {"DISPLAY":"1","ELECTRON_RUN_AS_NODE":"1","SSH_ASKPASS":"/home/krasznaa/.vscode/extensions/ms-vscode-remote.remote-ssh-0.55.0/out/local-server/askpass.sh","VSCODE_SSH_ASKPASS_NODE":"/snap/code/48/usr/share/code/code","VSCODE_SSH_ASKPASS_MAIN":"/home/krasznaa/.vscode/extensions/ms-vscode-remote.remote-ssh-0.55.0/out/askpass-main.js","VSCODE_SSH_ASKPASS_HANDLE":"/run/user/1000/snap.code/vscode-ssh-askpass-c6c8b6d3feab56fbab7b79e4a0a29fb16e78ab9f.sock"}
[14:31:14.641] Spawned 22165
[14:31:14.690] > local-server> Spawned ssh: 22176
[14:31:14.692] stderr> OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
[14:31:14.786] stderr> debug1: Server host key: ecdsa-sha2-nistp256 SHA256:AVfxgmsKrSpUdH22ntSP5QjsLtuLuHzO/LpnTU1dy8k
[14:31:15.270] stderr> Server not found in Kerberos database
[14:31:15.270] stderr> 
[14:31:15.270] stderr> 
[14:31:15.402] Got askpass request: {"request":"krasznaa@127.0.0.1's password:"}
[14:31:15.403] Showing password prompt
[14:31:15.404] Listening for interwindow password on /run/user/1000/snap.code/vscode-ssh-askpass-6305463f84aa8efdd8783998d5eaac11984ce354.sock
[14:31:15.404] Writing password prompt to globalState
[14:31:19.236] Got password response
[14:31:19.236] Interactor gave response: ***********
[14:31:19.237] Cleaning up other-window auth server
[14:31:19.566] stderr> Authenticated to 127.0.0.1 ([127.0.0.1]:1236).
[14:31:25.625] > ready: ac414cfbe745
[14:31:25.653] > Linux 4.18.0-193.1.2.el7.aarch64 #1 SMP Fri May 29 18:22:47 UTC 2020
[14:31:25.653] Platform: linux
[14:31:25.693] > ac414cfbe745: running
[14:31:25.760] > Acquiring lock on /afs/cern.ch/user/k/krasznaa/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a/vscode-remote-lock.krasznaa.d2e414d9e4239a252d1ab117bd7067f125afd80a
[14:31:25.763] > Installing to /afs/cern.ch/user/k/krasznaa/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a...
[14:31:25.763] > ac414cfbe745%%1%%
[14:31:25.767] > Downloading with wget
[14:31:28.475] > Download complete
> ac414cfbe745%%2%%
> tar --version:
[14:31:28.476] > tar (GNU tar) 1.26
> Copyright (C) 2011 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Written by John Gilmore and Jay Fenlason.
[14:31:40.929] > WARNING: VS Code Server is running but its logfile is missing. Don't delete the VS Code Server manually, run the command 'Uninstall VS Code Server'.
[14:31:40.929] > LC_PAPER=en_GB.UTF-8
> LC_ADDRESS=en_GB.UTF-8
> XDG_SESSION_ID=11969
> LC_MONETARY=en_GB.UTF-8
> HOSTNAME=techlab-arm64-thunderx2-01
> SELINUX_ROLE_REQUESTED=
> SHELL=/bin/bash
> HISTSIZE=1000
> SSH_CLIENT=137.138.55.107 49972 22
> SELINUX_USE_CURRENT_RANGE=
> LC_NUMERIC=en_GB.UTF-8
> QTDIR=/usr/lib64/qt-3.3
> QTINC=/usr/lib64/qt-3.3/include
> QT_GRAPHICSSYSTEM_CHECKED=1
> USER=krasznaa
> LC_TELEPHONE=en_GB.UTF-8
> AtlasSetup=/afs/cern.ch/atlas/software/dist/AtlasSetup
> VSCODE_AGENT_FOLDER=/afs/cern.ch/user/k/krasznaa/.vscode-server
> PATH=/usr/lib64/qt-3.3/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin
> MAIL=/var/spool/mail/krasznaa
> LC_IDENTIFICATION=en_GB.UTF-8
> PWD=/afs/cern.ch/user/k/krasznaa
> AFSHOME=/afs/cern.ch/user/k/krasznaa
> LANG=en_US.UTF-8
> MODULEPATH=/usr/share/Modules/modulefiles:/etc/modulefiles
> LC_MEASUREMENT=en_GB.UTF-8
> LOADEDMODULES=
> SELINUX_LEVEL_REQUESTED=
> KRB5CCNAME=FILE:/tmp/krb5cc_14308_ypwnPO
> HISTCONTROL=ignoredups
> HOME=/afs/cern.ch/user/k/krasznaa
> SHLVL=2
> AMIConfFile=/afs/cern.ch/user/k/krasznaa/private/ami.cfg
> RUCIO_ACCOUNT=akraszna
> LOGNAME=krasznaa
> QTLIB=/usr/lib64/qt-3.3/lib
> SSH_CONNECTION=137.138.55.107 49972 128.142.167.125 22
> MODULESHOME=/usr/share/Modules
> LESSOPEN=||/usr/bin/lesspipe.sh %s
> XDG_RUNTIME_DIR=/run/user/14308
> LC_TIME=en_GB.UTF-8
> LC_NAME=en_GB.UTF-8
> BASH_FUNC_module()=() {  eval `/usr/bin/modulecmd bash $*`
> }
> _=/usr/bin/printenv
> OLDPWD=/afs/cern.ch/user/k/krasznaa/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a
[14:31:40.930] > Starting server with command... /afs/cern.ch/user/k/krasznaa/.vscode-server/bin/d2e414d9e4239a252d1ab117bd7067f125afd80a/server.sh --host=127.0.0.1 --enable-remote-auto-shutdown --disable-telemetry --port=0 &> "/afs/cern.ch/user/k/krasznaa/.vscode-server/.d2e414d9e4239a252d1ab117bd7067f125afd80a.log" < /dev/null
[14:31:40.932] stderr> cat: /afs/cern.ch/user/k/krasznaa/.vscode-server/.d2e414d9e4239a252d1ab117bd7067f125afd80a.log: No such file or directory
[14:31:40.932] > Waiting for server log...
[14:31:41.436] > Waiting for server log...
[14:31:41.938] > Waiting for server log...
[14:31:42.441] > Waiting for server log...
[14:31:42.944] > Waiting for server log...
[14:31:43.447] > Waiting for server log...
[14:31:43.950] > Waiting for server log...
[14:31:44.451] >  
> *
> * Reminder: You may only use this software with Visual Studio family products,
> * as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)
> *
>  
[14:31:44.458] > Checking server status on port 40667 with wget
[14:31:44.474] > ac414cfbe745: start
> sshAuthSock====
> listeningOn==40667==
> osReleaseId==centos==
[14:31:44.474] > arch==aarch64==
> webUiAccessToken====
> tmpDir==/run/user/14308==
> platform==linux==
> ac414cfbe745: end
[14:31:44.475] Received install output: 
sshAuthSock====
listeningOn==40667==
osReleaseId==centos==arch==aarch64==
webUiAccessToken====
tmpDir==/run/user/14308==
platform==linux==

[14:31:44.475] Remote server is listening on 40667
[14:31:44.475] Parsed server configuration: {"remoteListeningOn":{"port":40667},"osReleaseId":"centos","arch":"aarch64","webUiAccessToken":"","sshAuthSock":"","tmpDir":"/run/user/14308","platform":"linux"}
[14:31:44.475] ** Note: Support for architecture "aarch64" is in preview **
[14:31:44.476] Persisting server connection details to /home/krasznaa/.config/Code/User/globalStorage/ms-vscode-remote.remote-ssh/vscode-ssh-host-thunderx2.cern.ch-d2e414d9e4239a252d1ab117bd7067f125afd80a-0.55.0/data.json
[14:31:44.478] Starting forwarding server. localPort 34219 -> socksPort 37927 -> remotePort 40667
[14:31:44.478] Forwarding server listening on 34219
[14:31:44.478] Waiting for ssh tunnel to be ready
[14:31:44.479] [Forwarding server 34219] Got connection 0
[14:31:44.480] Tunneled 40667 to local port 34219
[14:31:44.480] Resolved "ssh-remote+thunderx2.cern.ch" to "127.0.0.1:34219"
[14:31:44.494] ------

[14:31:44.543] [Forwarding server 34219] Got connection 1
[14:31:44.543] [Forwarding server 34219] Got connection 2
[14:35:44.410] Picking SSH host
[14:35:47.662] Selected thunderx2.cern.ch

It's worth mentioning that I am able to connect to x86 nodes that run CentOS 7 just fine. I only encountered this issue with an aarch64 node. So I'm pretty sure that that plays a key role here...

I guess "** Note: Support for architecture "aarch64" is in preview **" comes with such problems... :frowning:

roblourens commented 4 years ago

Is this still an issue?

krasznaa commented 4 years ago

I'm very confused. :confused: Is the issue closed? Should we say whether it's still an issue, what's happening?

In my limited testing it seems that CentOS 7 on aarch64 is not functioning correctly as an "SSH remote endpoint". CentOS 7 running on x86 does. Also, Raspberry Pi OS works correctly as a backend.

So it seems to be something unexpected happening on CentOS 7 aarch64 specifically. (I managed to reproduce the same behaviour on both "the main server" that I first saw this on, and then on a Raspberry Pi running CentOS 7. Both of them behaved the exact same way, failing with the exact same message.)

I know that this is a very niche problem. But it would definitely help me if it could be looked into. :wink:

roblourens commented 4 years ago

@Chuxel do you happen to know anything about this combination of OS and arch?

Chuxel commented 4 years ago

@roblourens Unfortunately I don't - I don't have a device with that combination either.

My guess is a glibc incompatibility specific to that architecture. @joaomoreno What is the minimum glibc/libc++ version right now for Aarch64? I know it went up when the VS Code ARM64/Aarch64 was in insiders, but we dropped it back down since it affected even Debian 9.

roblourens commented 4 years ago

I think this is also relevant, https://github.com/microsoft/vscode-remote-release/issues/3857#issuecomment-723272687 here it is complaining about missing 3.4.22

joaomoreno commented 4 years ago

@Chuxel You might be right, but I'm not so sure, since there's no error indicating that.

I can try to setup my RPi 4 with CentOS 7.4 aarch64 and see what's up.

roblourens commented 4 years ago

If it changed, then we should update https://code.visualstudio.com/docs/remote/linux and that sort of thing should be in the release notes too

joaomoreno commented 4 years ago

Holy cow, it's the first time I see that very comprehensive page. And yeah, the dependencies haven't changed. We went up then down, months ago.

roblourens commented 4 years ago

I don't know if this is the wrong place to look, but I'm trying to check it.

Looks like linux x64 wants 3.4.19

$ objdump -T node_modules/spdlog/build/Release/spdlog.node  | grep GLIBCXX
[...]
0000000000000000      DF *UND*  0000000000000000  GLIBCXX_3.4.19 _ZNSt6chrono3_V212system_clock3nowEv
[...]

and linux arm64 wants 3.4.22

$ objdump -x node_modules/spdlog/build/Release/spdlog.node | grep GLIBCXX
[...]
    0x0297f872 0x00 11 GLIBCXX_3.4.22
[...]

node in both cases wants 3.4.18

joaomoreno commented 4 years ago

@roblourens You're right, this is what happens when requiring spdlog on a brand new CentOS on ARM64:

[joao@joao-desktop 65f805d98e798b979901b74d4c8810c05455b792]$ ./node
Welcome to Node.js v12.14.1.
Type ".help" for more information.
> require('spdlog')
Thrown:
Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by /home/joao/.vscode-server-insiders/bin/65f805d98e798b979901b74d4c8810c05455b792/node_modules/spdlog/build/Release/spdlog.node)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1021:18)
    at Module.load (internal/modules/cjs/loader.js:811:32)
    at Function.Module._load (internal/modules/cjs/loader.js:723:14)
    at Module.require (internal/modules/cjs/loader.js:848:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at bindings (/home/joao/.vscode-server-insiders/bin/65f805d98e798b979901b74d4c8810c05455b792/node_modules/bindings/bindings.js:112:48)
joaomoreno commented 4 years ago

And there might be worse compats:

> require('vsda')
Thrown:
Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /home/joao/.vscode-server-insiders/bin/65f805d98e798b979901b74d4c8810c05455b792/node_modules/vsda/build/Release/vsda.node)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1021:18)
    at Module.load (internal/modules/cjs/loader.js:811:32)
    at Function.Module._load (internal/modules/cjs/loader.js:723:14)
    at Module.require (internal/modules/cjs/loader.js:848:19)
    at require (internal/modules/cjs/helpers.js:74:18)
joaomoreno commented 4 years ago

Related: https://stackoverflow.com/questions/55156942/deno-on-centos-7-glibc-2-18-not-found

Given that CentOS 8 is out (does the vscode server run on that?), I wonder if we should just drop CentOS 7 support.

krasznaa commented 4 years ago

I understand if you choose to do that (drop CentOS 7 support), but I do have to point out that a lot of organisations are still using CentOS 7 in production. CERN definitely does...

As another ingredient to the discussion, the VSCode RPM refuses to install on CentOS 7 AArch64.

[bash][rberry-4b]:~ > sudo yum install code
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: mirror.init7.net
 * extras: mirror.init7.net
 * updates: mirror.init7.net
code                                                                                             | 3.0 kB  00:00:00     
code/primary_db                                                                                  | 533 kB  00:00:00     
Resolving Dependencies
--> Running transaction check
---> Package code.aarch64 0:1.51.0-1604600268.el7 will be installed
--> Processing Dependency: libX11.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXcomposite.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXcursor.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXdamage.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXext.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXfixes.so.3()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXi.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXrandr.so.2()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXrender.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXss.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libXtst.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libasound.so.2()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libatk-1.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libcairo.so.2()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libcups.so.2()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libdbus-1.so.3()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libdl.so.2()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libexpat.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libfontconfig.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libfreetype.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgcc_s.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgcc_s.so.1(GCC_3.0)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgcc_s.so.1(GCC_4.0.0)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgdk-x11-2.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgdk_pixbuf-2.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgio-2.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libglib-2.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgmodule-2.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgobject-2.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libgtk-3.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libm.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libm.so.6(GLIBC_2.2.5)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libnspr4.so()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libnss3.so()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libnssutil3.so()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libpango-1.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libpangocairo-1.0.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libpthread.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libpthread.so.0(GLIBC_2.2.5)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libpthread.so.0(GLIBC_2.3.2)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libpthread.so.0(GLIBC_2.3.3)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: librt.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libsecret-1.so.0()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libsmime3.so()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.10)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.11)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.14)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.15)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.9)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libxcb.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libxkbfile.so.1()(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Processing Dependency: libc.so.6(GLIBC_2.11)(aarch64) for package: code-1.51.0-1604600268.el7.aarch64
--> Finished Dependency Resolution
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXdamage.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgobject-2.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgmodule-2.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libpthread.so.0(GLIBC_2.3.2)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXcursor.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgio-2.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libfontconfig.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libsecret-1.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6(GLIBCXX_3.4.9)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXrandr.so.2()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgdk_pixbuf-2.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgdk-x11-2.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6(GLIBCXX_3.4.14)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libpthread.so.0(GLIBC_2.3.3)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libxkbfile.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libpango-1.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXcomposite.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libdbus-1.so.3()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgcc_s.so.1(GCC_3.0)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libm.so.6(GLIBC_2.2.5)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgtk-3.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXss.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgcc_s.so.1(GCC_4.0.0)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libcairo.so.2()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: librt.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libatk-1.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libgcc_s.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libc.so.6(GLIBC_2.11)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libxcb.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libglib-2.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libfreetype.so.6()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libcups.so.2()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6(GLIBCXX_3.4)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6(GLIBCXX_3.4.10)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXi.so.6()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXext.so.6()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6(GLIBCXX_3.4.15)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libsmime3.so()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libpthread.so.0(GLIBC_2.2.5)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libnspr4.so()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXtst.so.6()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libdl.so.2()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libasound.so.2()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXrender.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libnssutil3.so()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libX11.so.6()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libexpat.so.1()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libstdc++.so.6(GLIBCXX_3.4.11)(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libpangocairo-1.0.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libpthread.so.0()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libXfixes.so.3()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libnss3.so()(aarch64)
Error: Package: code-1.51.0-1604600268.el7.aarch64 (code)
           Requires: libm.so.6()(aarch64)
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[bash][rberry-4b]:~ >

At least some of these seem to be red herrings though. For instance YUM complains about not being able to provide libstdc++.so.6 to the RPM. And yet:

[bash][rberry-4b]:~ > ls -l /usr/lib64/libstdc++.so*
lrwxrwxrwx. 1 root root      19 Aug  6  2019 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.19
-rwxr-xr-x. 1 root root 1057320 Aug  6  2019 /usr/lib64/libstdc++.so.6.0.19
[bash][rberry-4b]:~ >

So unfortunately it's not obvious from these messages alone what is really missing for VSCode on this OS/platform combination...

joaomoreno commented 4 years ago

@krasznaa Note that for the VS Code client, that's exactly why we ship a snap package: to avoid this dependency mess.

tysonite commented 4 years ago

That's really pity if you are going to drop support for < GLIBCXX_3.4.22 as in #3857.

Any chance you can link libstdc++ statically or ship it within?

Chuxel commented 4 years ago

@joaomoreno We should not drop CentOS 7 support. It's broadly used and isn't EOL until 2024.

joaomoreno commented 4 years ago

@Chuxel AFAIK CentOS 7 support for x64 is still OK. It's the ARM64 that seems broken.

krasznaa commented 4 years ago

@Chuxel AFAIK CentOS 7 support for x64 is still OK. It's the ARM64 that seems broken.

Correct. I regularly connect to x86 machines running CentOS 7 using SSH. That has worked reliably (as much as I can tell) ever since the remote-SSH feature was introduced.

Chuxel commented 4 years ago

@joaomoreno Oh weird - so CentOS ARM has older versions of these libraries than x86? That's super strange.

EDIT: Whoops - had that flipped like Rob says 👇

roblourens commented 4 years ago

I think its our binary that has a higher requirement in ARM than x86. https://github.com/microsoft/vscode-remote-release/issues/2998#issuecomment-725059164

What in the build determines this?

Also I should cc @deepak1556

joaomoreno commented 4 years ago

Our build environment for x64 is based on Ubuntu 14.04 which is Debian jessie: https://github.com/microsoft/vscode-linux-build-agent/blob/master/x64/Dockerfile

As for ARM, we're using stretch: https://github.com/microsoft/vscode-linux-build-agent/blob/master/stretch-arm64/Dockerfile

I'll see if we can create containers for jessie and see how the build ends up there.

joaomoreno commented 4 years ago

Yup now I remember:

W: Failed to fetch http://security.debian.org/debian-security/dists/jessie/updates/InRelease  Unable to find expected entry 'main/binary-arm64/Packages' in Release file (Wrong sources.list entry or malformed file)

W: Failed to fetch http://deb.debian.org/debian/dists/jessie-updates/InRelease  Unable to find expected entry 'main/binary-arm64/Packages' in Release file (Wrong sources.list entry or malformed file)

W: Failed to fetch http://deb.debian.org/debian/dists/jessie/Release  Unable to find expected entry 'main/binary-arm64/Packages' in Release file (Wrong sources.list entry or malformed file)

No proper arm64 multiarch support in debian jessie. The oldest release I could make it work on is stretch.

krasznaa commented 4 years ago

Since CentOS 7 is "older" than Debian Stretch, then why not make CentOS 7 "the build platform"? 😛

But to be more serious: Even on the newer Debian release, couldn't you set up the build against an older glibc version? As you can imagine we install all sorts of new software versions on CentOS 7, that's how it's still our production platform. (We don't just use GCC 4.8 on it exclusively.)

http://lcginfo.cern.ch/#platforms

I imagine downgrades should be possible like this as well, not just upgrades...

deepak1556 commented 4 years ago

@joaomoreno as @krasznaa suggests we can do two things on the build side to maintain support for older glibc versions,

1) Setup gcc toolchain from jessie on stretch which would pick up older GLIBCXX symbols from libstdc++ . As to what version of GLIBCXX can be supported is something to be tested on the device.

2) Keep the stretch gcc toolchain but install jessie libstdc++ and add it in LD_LIBRARY_PATH, so the compilation step will pick up symbols from it. Based on the available version, this can give support from >= GLIBCXX_3.4.20

On the user side:

@krasznaa can you download newer libstdc++ from CentOS 8 and use it via LD_LIBRARY_PATH ?

krasznaa commented 4 years ago

@krasznaa can you download newer libstdc++ from CentOS 8 and use it via LD_LIBRARY_PATH ?

Sure, I can work around the issue on my end. For now I've put the following into my ~/.bashrc script:

# Set up GCC 9 automatically on AArch64.
if [ `uname -n` = "techlab-arm64-thunderx2-01" ]; then
    echo "Setting up GCC 9 for aarch64"
    . /cvmfs/sft.cern.ch/lcg/contrib/gcc/9/aarch64-centos7/setup.sh
fi

(I don't have administrative rights for that machine, and we have a shared home directory for a lot of different machines/platforms.)

However something easier would certainly be welcome.

Cheers, Attila

P.S. To make it clear, with this in place I am able to make use of that node through remote-SSH.

stygarfield commented 3 years ago

This looks a lot like the error we're getting here

https://github.com/microsoft/vscode-remote-release/issues/4087

Did anyone find a fix that works on a rasberry pi?

Linux version 5.4.72-v7+ (dom@buildbot) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #1356 SMP

darrenkenny commented 3 years ago

For the record, I'm seeing this same problem with GLIBC on Oracle Linux 7, which is similar to CentOS 7 and RHEL 7 - where the version of libstdc++.so.6 doesn't contain the GLIBCXX_3.4.22 that is being required, it only goes up to GLIBC_3.4.21.

*
* Visual Studio Code Server
*
* Reminder: You may only use this software with Visual Studio family products,
* as described in the license https://aka.ms/vscode-remote/license
*

IP Address: 100.100.230.168
IP Address: 172.17.0.1
Extension host agent listening on 39571

[09:39:41] Extension host agent started.
Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /home/darrenk/.vscode-server-insiders/bin/f47aae014cf8567f648e68369d66b4106ae89f08/node_modules/spdlog/build/Release/spdlog.node)
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1187:18)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Module.require (internal/modules/cjs/loader.js:1025:19)
    at require (internal/modules/cjs/helpers.js:72:18)

I'm running the latest binaries on OL7.

This is only happening to me since updating to the latest viscose insider builds, if I downgrade to a version from several weeks back, it works fine again - so I'm presuming there has been some upgrade on the builds of the remote end binaries.

The version that works for me is:

Version: 1.52.0-insider
Commit: 24b28f57be22fe3029cb17a1dd72d8d9c2d6468b
Date: 2020-11-06T05:39:23.276Z
Electron: 9.3.3
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Darwin x64 19.6.0

I've tried using the OL8 version of the library, but it doesn't work since it starts to drag in other libraries, and eventually fails because the ld-linux.so version is also wrong.

But really, as I think mentioned elsewhere, the binaries on the remote side should probably be statically linked if at all possible to avoid this kind of versioning issue - somewhat akin to what the 'go' language does here for that same reason.

Fydon commented 3 years ago

Sorry if I'm posting when it isn't necessary, but I'm getting this error on Ubuntu 16.04 for x86_64 so just want to be sure that the ARM fix will work for me as well.

Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.22' not found (required by /home/ubuntu/.vscode-server-insiders/bin/0a80aacc7be1ab03ec0f94b8ac1a84949a83f35d/node_modules/spdlog/build/Release/spdlog.node)
strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX_3.4.2
GLIBCXX_3.4.2
GLIBCXX_3.4.20
GLIBCXX_3.4.21

I'm using the following version of VSCode

Version: 1.52.0-insider (system setup)
Commit: 0a80aacc7be1ab03ec0f94b8ac1a84949a83f35d
Date: 2020-11-26T07:36:22.965Z
Electron: 11.0.2
Chrome: 87.0.4280.63
Node.js: 12.18.3
V8: 8.7.220.24-electron.0
OS: Windows_NT x64 10.0.19042
deepak1556 commented 3 years ago

@Fydon it is a side effect of updating our build system to Ubuntu bionic for newer electron runtime. Thanks for reporting it but can you create a separate issue.

I won't be able to tackle this issue since I lack the setup to verify the changes.

tysonite commented 3 years ago

@deepak1556, is there anything we can do to help you verify changes on target?

jnchaba commented 2 years ago

Hi, I'm wondering if this issue is still being worked on? I encountered this today when trying to connect to a Centos 7 ARM64 Docker container provisioned by Vagrant. It worked perfectly with a Centos 7 x86_64 image, but complains about an unsupported server for ARM64.

abarberenaCPDS commented 2 years ago

As noted, open-ssh server may not work yet with CentOS AArch64 distro.

Still figuring out another way.

image

Also, as noted by the Remote - SSH extension

image
abarberenaCPDS commented 2 years ago

Alternative approach - using RMATE

This has worked very well for me in the past, Using Remote VSCode Setup.

Just keep in mind using the right syntax if needed, user@IP.

$ ssh -R 52698:localhost:52698 user@VIRTUAL_MACHINE_IP_ADDRESS
image

My Rig