Can't connect to CentOS 7 ARM64 #2998
Comments
|
Judging from the amount of new tickets unanswered, I imagine I'll be waiting a while for any help. |
|
I ran into the same problem, help wanted! |
|
as a workaround, and "re setup" ssh by following (again): |
|
@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 and |
|
I'm getting the same problem as @LukeIreland1, has this been resolved for you? |
|
+1 for me, any news on this? |
|
I'm getting the same error. 😦 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: 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 " |
|
Is this still an issue? |
|
I'm very 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. 😉 |
|
@Chuxel do you happen to know anything about this combination of OS and arch? |
|
@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. |
|
I think this is also relevant, #3857 (comment) here it is complaining about missing 3.4.22 |
|
@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. |
|
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 |
|
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. |
|
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 and linux arm64 wants 3.4.22 node in both cases wants 3.4.18 |
|
@roblourens You're right, this is what happens when requiring |
joaomoreno
changed the title
|
And there might be worse compats: |
|
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. |
|
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. At least some of these seem to be red herrings though. For instance YUM complains about not being able to provide So unfortunately it's not obvious from these messages alone what is really missing for VSCode on this OS/platform combination... |
|
@krasznaa Note that for the VS Code client, that's exactly why we ship a snap package: to avoid this dependency mess. |
|
Yup now I remember: No proper arm64 multiarch support in debian jessie. The oldest release I could make it work on is stretch. |
|
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... |
|
@joaomoreno as @krasznaa suggests we can do two things on the build side to maintain support for older glibc versions,
On the user side: @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 # 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, P.S. To make it clear, with this in place I am able to make use of that node through remote-SSH. |
|
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. 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: 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. |
|
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. I'm using the following version of VSCode |
|
@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. |
|
@deepak1556, is there anything we can do to help you verify changes on target? |
|
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. |
|
As noted, open-ssh server may not work yet with CentOS AArch64 distro. Still figuring out another way.
Also, as noted by the Remote - SSH extension
|
Alternative approach - using RMATEThis 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
My Rig
|
tanhakabir
added
the
author-verification-requested
and others
Steps to Reproduce:
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.
The text was updated successfully, but these errors were encountered: