原因![]()
VS Code升级1.85以上后，隐性升级了捆绑的node版本，vscode-server的node依赖于GLIBC_2.28（使用旧版本等于丧失新功能使用权，而且设置也可能无法同步）
常见报错
sh: 1: /scripts/wslServer.sh: not found
升级后，由于关闭了wsl自动挂载，需把对应部分全删去（可以做好部分）
vim /etc/wsl.conf/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
node需要GLIBC_2.28支持，而Ubuntu 18.04最高支持GLIBC_2.27
GLIBC
支持的 glibc 版本”就是仓库里 libc6 软件包对应的版本
查看系统对应版本
ldd = “list dynamic dependencies”
ldd --version查看还可安装版本
apt-cache policy libc6查看libc 支持的最高/最低版本
strings /lib/x86_64-linux-gnu/libc.so.6 | grep GLIBC_查看自装的glibc-2.28
strings /opt/glibc-2.28/lib/libc.so.6 | grep GLIBC_strings /opt/glibc-2.28/lib/libc.so.6 | grep -E '^GLIBC_'Node.js(扩展)
node=Node.js 运行时主程序（ELF 可执行）
作用：把 JavaScript 搬到服务器、命令行、桌面” 的 跨平台运行时 + 海量生态
nvm 管 Node 版本 → Node 自带 npm → npm 管 JS 包
安装指定版本node
nvm install 20查看已安装node版本
nvm ls切换node版本
nvm use 20.0.0卸载node版本
nvm uninstall 18.10.8解决办法
// 编译并覆盖安装glibc（libc6），否则导致系统异常崩溃
让VS Code 的远程连接node脱离系统 glibc，指向自定义 GLIBC-2.28
手动编译GLIBC-2.28
// 自定义目录保存源码 mkdir ~/lib/glibc-2.28/src/ cd ~/lib/glibc-2.28/src/ //下载源码 wget 'https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.gz' tar xzf glibc-2.28.tar.gz // 必须指定prefix，作用就是“告诉构建系统：安装时把文件放到哪里” mkdir glibc-2.28-build cd glibc-2.28-build ../glibc-2.28/configure --prefix=/opt/glibc-2.28 // 编译源码 make // 安装到指定目录 sudo make installprefix：
不会影响系统/lib/x86_64-linux-gnu/libc.so.6，也不会自动被任何程序找到；
谁想用，就必须手动指定
安装之后得到
/opt/glibc-2.28/lib/libc.so.6 /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 /opt/glibc-2.28/include/...修改node
进入报错目录下的node节点
~/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node做好node备份
cp node node.bak把node链接到我们安装的glibc-2.28上
按其它友友们的说下，以下任选一行，即可VS远程即可正常
方法一
patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu node方法二
patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib:/usr/lib/x86_64-linux-gnu --force-rpath nodeVS Code 用的 node 没走你的特制 ld.so，于是找不到libgcc_s.so.1
~/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
比较方法一，其搜库路径是先 2.28 → 再系统 /lib → 再 /usr/lib
缺失了系统/lib，加上即可
--force-rpath不建议使用，“强行写老段”——优先级更高、无法被环境变量覆盖、已过时；无特殊兼容性需求就别加。
patchelf --set-interpreter /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --set-rpath /opt/glibc-2.28/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu --force-rpath node方法三
若以上方法还是不行
直接在终端里生成一个小脚本，把原 node 二进制换成一个 shell wrapper
这个方法虽然能连上，但vs的功能基本上都用不了，“自废武功”
wrapper 脚本就是“壳”脚本——本身不是真正的可执行文件，但同名同路径，先被系统调到，内部再帮你把真实程序拉起来，顺便偷偷加点料（比如换 glibc、加环境变量、改参数等）
cat > /home/chenkang/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node <<'EOF' #!/bin/bash exec /opt/glibc-2.28/lib/ld-linux-x86-64.so.2 --library-path /opt/glibc-2.28/lib:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu /home/chenkang/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node.real "$@" EOF chmod +x /home/chenkang/.vscode-server/bin/94e8ae2b28cb5cc932b86e1070569c4463565c37/node解析
- ld-linux-x86-64.so.2
ld.so 就是Linux 的“动态链接加载器”（/lib*/ld-linux*.so.2），内核 execve 任何动态链接 ELF 时第一个被拉进内存的程序——负责把可执行文件和所有 .so 库真正拼接成可运行进程，然后才把控制权交给你的 main。
patchelf 改 interpreter/rpath≈ 给自家车库装了自动门，车一靠近就自己开。
--set-rpath：按顺序搜库，把搜库路径焊进文件里，一次修改永久生效。
--set-interpreter：改写 ELF 可执行文件“解释器”路径，谁运行 node 都会先加载你指定的 ld.so
exec + --library-path≈ 每次出门都手动打一次网约车；
--library-path：手动选库路径开关，它只在那一次启动生效，不会写进可执行文件
验证
ldd node就是 "让 ld.so 预演一遍加载过程”，把最终选中的库路径逐行打印出来"，用来快速判断 node 实际会吃哪份 glibc
修改node链接前
修改node链接后
