Change:
x86_64) LDCONFIG_ARCH="x86-64";; armv7l | armv8l) LDCONFIG_ARCH="hard-float";; arm64 | aarch64) <ins> BITNESS=$(getconf LONG_BIT) </ins> if [ "$BITNESS" = "32" ]; then # Can have 32-bit userland on 64-bit kernel LDCONFIG_ARCH="hard-float"

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --The issue involves connecting to a host via SSH, and occurs when installing the updated version of vscode-server on the host. This worked with the same client/host on a previous version of VS Code. Version: 1.86.0 Commit: Date: 2024-01-31T10:29:11.933Z Electron: 27.2.3 ElectronBuildId: Chromium: 118.0.5993.159 18.17.1 V8: 11.8.172.18-electron.0 OS: Darwin arm64 23.3.0 Synology DS920+ OS: Linux slon 4.4.302+ SMP Mon Nov 13 14:19:30 CST 2023 x8664 GNU/Linux synologygeminilake920+ vs code and ssh remote extension to remote host running synology (ssh must be enabled on host, tcp forwarding enabled) Connection fails with an error saying because this distro does not ship with , but nonetheless has the correct version of glibc and other dependencies. This seems to come from the following line of code: As a workaround, I've been able to create and have a functioning setup. This confirms that the requirements are actually met. It seems like the variable only matters for arm64 and aarch64 systems. It would make sense to rewrite the script to only do the check when it is necessary, in order to maximize compatibility. I'm going through the script manually line by line to spot other issues. It's mostly fine on my host.

On some hosts, may also not be present. (Such as Synology NAS, which is perfectly capable of running this software). It is only used to detect nixos and alpine linux. Perhaps this lookup can also be moved to the appropriate places for compatibility. Alternately, can't give this answer? One other thing to note is the the libstdcpp versino detection. It seems to be incorrect. Checks for a specific version 6.0.25, but will throw a warning if a newer version, such as 6.0.31 is reported on the lines above in the variable
I am having the exact same problem. Thanks for raising this, otherwise I would have done the same.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
are there steps for this? Seems like the default Alpine image has both getconf and /etc/os-release, so I'm not sure what I should test on.
Issue requires a custom linux variant which I also don't have steps to verify, but the fix was verified in by another user on similar setup.
The insiders build Is is working as expected for me. Tested it on a Synology DS918+, 4.4.302+ SMP Fri Jan 12 17:02:59 CST 2024 x8664 GNU/Linux synologyapollolake_918+
It doesn't work in my case. It keeps asking for what distribution is installed once the VSCode server is installed. ! ! !
/verified
Also not working for me (neither in vscode nor insiders). Only works if I add the file
Can we reopen that?
related to ?
Can confirm the issue with ssh setup, will track it in