microsoft / microsoft/vscode-remote-release

Remote-SSH incorrectly detects Yocto/glibc system as Alpine/musl

Open
#11,293 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

ssh
Dominant language
Dockerfile
Stars
4.2k
Forks
469
Avg merge
1d 1h
Merged PRs (30d)
1

Description

Is there an existing issue for this bug?
  • I have searched the existing open issues and found none that apply.
  • If I find any issue of interest that is related or closed, I will included a link to it in this issue.
Required Troubleshooting Steps
  • I have read and performed the troubleshooting steps
  • I have tried both values of the remote.SSH.useLocalServer setting
  • My issue was not covered in the Tips and Tricks linked from the Troubleshooting Wiki.
  • I will include a complete copy of my Remote - SSH logs by running Remote-SSH: Show Log in the command palette or from View > Output in the menu bar
[Optional] Diagnose with Copilot

I asked @remote-ssh but it did not help

In step 2 of the troubleshooting wiki, what was the result of running the generated SSH command verbatim outside of VS Code?

I did not try step 2 of the troubleshooting steps

Remote-SSH Log
Remote-SSH Log 

[12:13:20.000] Log Level: 2
[12:13:20.013] SSH Resolver called for "ssh-remote+172.16.94.31", attempt 1
[12:13:20.016] remote.SSH.useLocalServer = false
[12:13:20.016] remote.SSH.useExecServer = true
[12:13:20.016] remote.SSH.bindHost = {}
[12:13:20.017] remote.SSH.showLoginTerminal = false
[12:13:20.017] remote.SSH.remotePlatform = {"172.16.94.31":"linux"}
[12:13:20.017] remote.SSH.path = 
[12:13:20.017] remote.SSH.configFile = 
[12:13:20.017] remote.SSH.useFlock = true
[12:13:20.017] remote.SSH.lockfilesInTmp = false
[12:13:20.017] remote.SSH.localServerDownload = auto
[12:13:20.017] remote.SSH.remoteServerListenOnSocket = false
[12:13:20.017] remote.SSH.defaultExtensions = []
[12:13:20.017] remote.SSH.defaultExtensionsIfInstalledLocally = []
[12:13:20.017] remote.SSH.loglevel = 2
[12:13:20.018] remote.SSH.enableDynamicForwarding = true
[12:13:20.018] remote.SSH.enableRemoteCommand = false
[12:13:20.018] remote.SSH.serverPickPortsFromRange = {}
[12:13:20.018] remote.SSH.serverInstallPath = {"172.16.94.31":"/home/strymon/.vscode-server"}
[12:13:20.018] remote.SSH.permitPtyAllocation = false
[12:13:20.018] remote.SSH.preferredLocalPortRange = undefined
[12:13:20.018] remote.SSH.useCurlAndWgetConfigurationFiles = false
[12:13:20.018] remote.SSH.experimental.chat = true
[12:13:20.018] remote.SSH.experimental.enhancedSessionLogs = true
[12:13:20.018] remote.SSH.httpProxy = {"*":""}
[12:13:20.018] remote.SSH.httpsProxy = {"*":""}
[12:13:20.025] VS Code version: 1.105.1
[12:13:20.025] Remote-SSH version: remote-ssh@0.120.0
[12:13:20.025] win32 x64
[12:13:20.027] SSH Resolver called for host: 172.16.94.31
[12:13:20.027] Setting up SSH remote "172.16.94.31"
[12:13:20.035] Using commit id "7d842fb85a0275a4a8e4d7e040d2625abbf7f084" and quality "stable" for server
[12:13:20.035] Extensions to install: 
[12:13:20.039] Install and start server if needed
[12:13:20.041] Checking ssh with "C:\WINDOWS\system32\ssh.exe -V"
[12:13:20.043] Got error from ssh: spawn C:\WINDOWS\system32\ssh.exe ENOENT
[12:13:20.043] Checking ssh with "C:\WINDOWS\ssh.exe -V"
[12:13:20.044] Got error from ssh: spawn C:\WINDOWS\ssh.exe ENOENT
[12:13:20.045] Checking ssh with "C:\WINDOWS\System32\Wbem\ssh.exe -V"
[12:13:20.045] Got error from ssh: spawn C:\WINDOWS\System32\Wbem\ssh.exe ENOENT
[12:13:20.045] Checking ssh with "C:\WINDOWS\System32\WindowsPowerShell\v1.0\ssh.exe -V"
[12:13:20.046] Got error from ssh: spawn C:\WINDOWS\System32\WindowsPowerShell\v1.0\ssh.exe ENOENT
[12:13:20.046] Checking ssh with "C:\WINDOWS\System32\OpenSSH\ssh.exe -V"
[12:13:20.066] > OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2

[12:13:20.069] Running script with connection command: "C:\WINDOWS\System32\OpenSSH\ssh.exe" -T -D 60405 "172.16.94.31" sh
[12:13:20.070] Generated SSH command: 'type "C:\Users\gregg\AppData\Local\Temp\vscode-linux-multi-line-command-172.16.94.31-867590506.sh" | "C:\WINDOWS\System32\OpenSSH\ssh.exe" -T -D 60405 "172.16.94.31" sh'
[12:13:20.071] Using connect timeout of 17 seconds
[12:13:20.071] Terminal shell path: C:\WINDOWS\System32\cmd.exe
[12:13:20.285] > 
[12:13:20.286] Got some output, clearing connection timeout
[12:13:22.184] > strymon@172.16.94.31's password:
[12:13:22.184] Showing password prompt
[12:13:27.292] Got password response
[12:13:27.292] "install" wrote data to terminal: "********"
[12:13:27.322] > 
[12:13:27.602] > 9e67617f8916: running
> Script executing under PID: 515
[12:13:27.635] > Installing to /home/strymon/.vscode-server/.vscode-server...
> 9e67617f8916%%1%%
> Downloading with wget
> wget is from busybox: no
> Program 'wget' appears to support flag '--no-config'
[12:13:28.226] > Download complete
[12:13:28.241] > 9e67617f8916%%2%%
> tar --version: tar (GNU tar) 1.35
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <https://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.
[12:13:28.426] > code 1.105.1 (commit 7d842fb85a0275a4a8e4d7e040d2625abbf7f084)
[12:13:28.442] > Starting VS Code CLI...
> Spawned remote CLI: 569
> Waiting for server log...
[12:13:28.455] > Exec server process not found
> main: line 418: kill: (569) - No such process
> [2025-11-03 19:13:29] error This machine does not meet Visual Studio Code Server's prerequisites, expected either...
>   - find /lib/ld-musl-x86_64.so.1, which is required to run the Visual Studio Code Server in musl environments
> 9e67617f8916: start
> exitCode==207==
> listeningOn====
> osReleaseId==debian==
> arch==x86_64==
> vscodeArch==x64==
> bitness==64==
> tmpDir==/run/user/1000==
> platform==linux==
> unpackResult==success==
> didLocalDownload==0==
> downloadTime==1000==
> installTime==0==
> serverStartTime====
> execServerToken==a111aa1a-11aa-11a1-a11a-1a11a11a111a==
> platformDownloadPath==cli-alpine-x64==
> SSH_AUTH_SOCK====
> DISPLAY====
> 9e67617f8916: end
[12:13:28.455] Received install output: 
exitCode==207==
listeningOn====
osReleaseId==debian==
arch==x86_64==
vscodeArch==x64==
bitness==64==
tmpDir==/run/user/1000==
platform==linux==
unpackResult==success==
didLocalDownload==0==
downloadTime==1000==
installTime==0==
serverStartTime====
execServerToken==a111aa1a-11aa-11a1-a11a-1a11a11a111a==
platformDownloadPath==cli-alpine-x64==
SSH_AUTH_SOCK====
DISPLAY====

[12:13:28.456] Resolver error: Error: The remote host does not meet the prerequisites for running VS Code Server
    at y.ServerInstallError (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:744694)
    at p (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:739113)
    at t.handleInstallOutput (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:740589)
    at t.tryInstall (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:865534)
    at async c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:824246
    at async t.withShowDetailsEvent (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:827501)
    at async A (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:820760)
    at async t.resolve (c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:824898)
    at async c:\Users\gregg\.vscode\extensions\ms-vscode-remote.remote-ssh-0.120.0\out\extension.js:2:1113660
[12:13:28.459] ------




[12:13:28.459]  ---------- [Session Summary] ----------- 
[12:13:28.459] [LinuxPrereqs]: The remote host may not meet VS Code Server's prerequisites for glibc and libstdc++ (The remote host does not meet the prerequisites for running VS Code Server)
[12:13:28.460]  ---------------------------------------- 
[12:13:28.834] > 
[12:13:29.736] "install" terminal command done
[12:13:29.736] Install terminal quit with output:

Expected Behavior

Connects to remote system

Actual Behavior

Title: Remote-SSH incorrectly detects Yocto/glibc systems as Alpine/musl despite all standard detection indicators

VSCode Version: 1.105.1 (commit 7d842fb85a0275a4a8e4d7e040d2625abbf7f084)Remote-SSH Extension: 0.120.0OS: Windows 10/11 (client), Yocto Linux x86_64 (target)

Problem Description

Remote-SSH consistently misdetects a glibc-based Yocto Linux system as Alpine/musl, downloading the wrong server binary (cli-alpine-x64 instead of cli-linux-x64) and failing with exit code
207.

Target System Configuration

System properly configured with all standard glibc indicators:

os-release

$ cat /etc/os-release
ID=debian
ID_LIKE=debian
VERSION_ID="12"

glibc 2.39 present

$ strings /lib/libc.so.6 | grep GLIBC_2
GLIBC_2.28
GLIBC_2.29
...
GLIBC_2.39

Standard glibc dynamic linker (both paths)

$ ls -la /lib/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 223032 /lib/ld-linux-x86-64.so.2

$ ls -la /lib64/ld-linux-x86-64.so.2
-rwxr-xr-x 1 root root 223032 /lib64/ld-linux-x86-64.so.2

Debian multiarch directories present

$ ls -la /lib/x86_64-linux-gnu/
drwxr-xr-x 2 root root 4096 .
lrwxrwxrwx 1 root root 10 libc.so.6 -> ../libc.so.6
lrwxrwxrwx 1 root root 12 libm.so.6 -> ../libm.so.6
[...standard glibc libraries via symlinks...]

Architecture

$ uname -m
x86_64

NO musl present

$ ls /lib/ld-musl*.so.1 2>&1
ls: cannot find /lib/ld-musl*.so.1: No such file or directory

Note: System uses BusyBox for some utilities (ls, head, etc.) but with glibc, not musl. This is standard for Yocto/Buildroot/OpenWrt systems.

Detection Output (from Remote-SSH logs)

osReleaseId==debian== ✓ Correct
arch==x86_64== ✓ Correct
platform==linux== ✓ Correct
platformDownloadPath==cli-alpine-x64== ✗ WRONG (should be cli-linux-x64)

Error Result

[2025-11-03 18:42:49] error This machine does not meet Visual Studio Code Server's prerequisites, expected either...
- find /lib/ld-musl-x86_64.so.1, which is required to run the Visual Studio Code Server in musl environments
exitCode==207==

The downloaded cli-alpine-x64 binary is linked against musl and cannot run on this glibc system.

Root Cause Analysis

VSCode's detection appears to:

  1. ✓ Correctly identify ID=debian and platform=linux
  2. ✗ See BusyBox in the environment
  3. ✗ Assume "BusyBox = Alpine = musl" regardless of actual libc
  4. ✗ Ignore all glibc indicators (/lib64/ld-linux-x86-64.so.2, multiarch dirs, etc.)

BusyBox is NOT an indicator of musl. Many production embedded Linux systems use BusyBox + glibc:

  • Yocto Project
  • Buildroot (configurable)
  • OpenWrt (some configs)
  • Custom embedded distributions

Exhaustive Workarounds Attempted (ALL FAILED)

  1. Setting Configuration

{
"remote.SSH.remotePlatform": {
"172.16.94.31": "linux"
}
}
Result: No change, still detects as Alpine

  1. Server Install Path

{
"remote.SSH.serverInstallPath": {
"172.16.94.31": "/home/strymon/.vscode-server"
}
}
Result: No change

  1. Manual Server Installation

Pre-installed correct cli-linux-x64 server at proper path with correct commit ID.Result: VSCode ignored it and re-downloaded cli-alpine-x64

  1. Environment Variable (via .bashrc)

echo 'export VSCODE_REMOTE_SSH_SERVER_PLATFORM=linux-x64-glibc' >> ~/.bashrc
Result: Not read by non-interactive SSH session

  1. Environment Variable (via ~/.ssh/rc)

cat > ~/.ssh/rc << 'EOF'
#!/bin/sh
export VSCODE_REMOTE_SSH_SERVER_PLATFORM=linux-x64-glibc
EOF
chmod 755 ~/.ssh/rc
Result: No change, still downloads Alpine binary

  1. Modified /etc/os-release

Changed from ID=poky to ID=debian with ID_LIKE=debian.Result: Detection logs show osReleaseId==debian but still chooses Alpine

  1. Added /lib64 symlink

Created /lib64 -> /lib symlink so /lib64/ld-linux-x86-64.so.2 exists.Result: No change

  1. Added Debian multiarch directories

Created /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu/ with symlinks to glibc libraries.Result: No change

Requested Fix

  1. Improve Detection Logic

Check for actual dynamic linker presence:

glibc system

if [ -e /lib/ld-linux-x86-64.so.2 ] || [ -e /lib64/ld-linux-x86-64.so.2 ]; then
# This is glibc, use cli-linux-x64
fi

musl system

if [ -e /lib/ld-musl-x86_64.so.1 ]; then
# This is musl, use cli-alpine-x64
fi

Do NOT assume BusyBox presence means musl.

  1. Add Manual Override Setting

New setting: remote.SSH.serverPlatform
{
"remote.SSH.serverPlatform": {
"172.16.94.31": "linux-x64-glibc" // or "linux-x64-musl" or "auto"
}
}

This allows users to explicitly force correct binary selection when auto-detection fails.

  1. Respect Environment Variable

Honor VSCODE_REMOTE_SSH_SERVER_PLATFORM environment variable on remote host (currently appears to be ignored).

Impact

This issue affects all embedded Linux development using:

  • Yocto Project (Poky)
  • Buildroot (common configurations)
  • OpenWrt (some configurations)
  • Any custom embedded Linux using BusyBox + glibc

These are mainstream embedded development platforms, not edge cases.

System Details

  • Host OS: Windows 10/11
  • Remote OS: Yocto Linux (Poky 5.0.13)
  • Target Machine: intel-corei7-64
  • Kernel: 6.17.0-evl (EVL/Xenomai 4)
  • libc: glibc 2.39
  • BusyBox: v1.36.1 (for some utilities, but system uses glibc)
  • wget: GNU Wget 1.21.4 (NOT BusyBox)

Additional Logs Available

Can provide:

  • Complete Remote-SSH connection logs
  • Target system ldd --version output (ldd not available in minimal Yocto)
  • Full /etc/os-release contents
  • Directory listings of loader paths
Steps To Reproduce

F1 connect to remote

Anything else?

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the Remote-SSH connection against the supplied Yocto/glibc target and compare the logged platformDownloadPath with the reported libc and BusyBox indicators. Trace the Remote-SSH server platform and prerequisite detection described by the logs. Done means the target receives cli-linux-x64 rather than cli-alpine-x64 and the connection succeeds.

Written by the indexing model from the issue text.

Assessment

Tech stack
linux
Domain
devtools, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.