Cannot open remote terminal when connecting to RHEL 8.10 system
Describe the bug I use this extention open remote ssh to connect to a RHEL 8.10 based system. When I opened the terminal, there were no shell prompt shown.
After a while, the following message was shown.
Please confirm that this problem is VSCodium-specific
- [x] This bug doesn't happen if I use Microsoft's Visual Studio Code. It only happens in VSCodium.
Please confirm that the issue/resolution isn't already documented
- [x] I checked the Docs page and the Troubleshooting page and my issue is not mentioned there.
To Reproduce Steps to reproduce the behavior:
- Install the extension open remote ssh.
- Connect to a RHEL 8.10 remote host.
- Open the terminal
- There are no shell prompt shown and any message shown. The terminal is not usable.
Expected behavior A clear and concise description of what you expected to happen.
- The shell prompt should be shown.
- You can use the terminal.
Screenshots If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: Windows 11
- Architecture: x64
- Version: 1.104.16282
- App Manager: Use exe installer
- Sandboxed: no
Additional context Add any other context about the problem here.
The same problem here. For the context:
I'm on MacOS ARM64
Tried to connect to ubuntu machine via Open remote ssh plugin. Goes ok, but terminal never opened. Had the same Pty Host button that didn't do anything.
Tried to install different versions from the latest (VSCodium.arm64.1.104.36664.dmg) going down one by one until the version VSCodium.arm64.1.103.15418.dmg (or mby something close). And that's where it just magically started working. Terminal is opening just fine, the commands can be executed etc.
PS. terminal worked for some of my ubuntu machines (on the latest version) and I don't know why. Now it works for all of them.
Having the same issue on Ubuntu with x86_64 architecture, using the same plugin. No problem viewing files on a remote server, but the terminal just hangs and I have the Pty Host button which, as stated above, does nothing.
The REH x64 version is packed with the nodejs for glibc-2.17 for more compatibility.
Some dependencies ship binary, I recompile most with the _GLIBCXX_USE_CXX11_ABI=0 flag.
https://github.com/VSCodium/vscodium/blob/22d1929f41180055fc0478f0b3da08b4e6b1e92a/build/linux/package_reh.sh#L180
One of those dependencies is node-pty but it pass my verify_cxx11_requirements.sh verification.
I've tested on an Ubuntu 22.04 and I don't have any issue.
Can you check the logs on:
- the server
- in
View/Outputand:- Pty Host (Remote)
- Server
Can you list the Ubuntu version?
You can also try to replace the node binary... (under ~/.mrcode-server/bin/)
I tryed these machine with vscodium version 1.105:
- [x] Debian Bookworm
- [ ] Debian Bullseye
- [ ] Debian Buster, with vscode old linux faq
now use version 1.103.15418, it's worked
On all the remote machines I connect to with GLIBC==2.28, I get the error mentioned in the OP, but not on the machines with GLIBC==2.34.
@daiyam Do you think this bug might somehow be related?
I have this problem with centos 8 (this is as well stuck on GLIBC 2.28). The node-pty extention reports missing GLIBC 2.34.
According to the server log it tries to download the current version for RHEL.
IPC Library: Pty Host] Uncaught Exception: Error: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ~/.vscodium-server/bin/03d61e1799ba4597c64a6c0ae65316d95b2c2937/node_modules/node-pty/build/Release/pty.node)
I tried to replace the node binary with no success. Is there maybe an easy way to fix the pty version to something supporting GLIBC 2.28 for LTS and slow to update distros?
Since I spend way to long to fix it, I might as well share the streamlined version of the workaround I developed over the past hours. I'm currently serverside running vscode:
v. 1.106.37943
03d61e1799ba4597c64a6c0ae65316d95b2c2937
I replaced the node version shipped by open-remote-ssh with node version 20.19.6. (I symlinked it ln -s $(which node) ~/.vscode-server/bin/03d61e1799ba4597c64a6c0ae65316d95b2c2937/), then run npm rebuild in ~/.vscode-server/bin/03d61e1799ba4597c64a6c0ae65316d95b2c2937/node_modules/
I used npm to manually install packages that where declared missing in the server log:
cookie
@vscode/spdlog
@vscode/deviceid
@vscode/ripgrep
@vscode/proxy-agent
vscode-regexpp
@parcel/watcher
@xterm/headless
If something else is missing it show up in the log file (found at ~/.vscode-server/.03d61e1799ba4597c64a6c0ae65316d95b2c2937.log or the hash of your version).
finally restarted server component by kill $(cat "$HOME/.vscode-server/.03d61e1799ba4597c64a6c0ae65316d95b2c2937.pid"), reconnected vscode and the shell and pty-host is back!
Thank you for the workaround! I'll get around to testing it on my machine when I get the time.
Is this an issue with open-remote-ssh? Any idea where this should be reported upstream for a fix/PR?
Is this an issue with
open-remote-ssh?
No. VSCodium
Any idea where this should be reported upstream for a fix/PR?
The
This need to be changed.reh is packaged with node-v16 for compatibility but extensions are breaking it.
Edit: it's due to glibc-217 from https://unofficial-builds.nodejs.org
Can you the Insider version https://github.com/VSCodium/vscodium-insiders/releases/tag/1.107.08447-insider? Thx
Can you the Insider version https://github.com/VSCodium/vscodium-insiders/releases/tag/1.107.08447-insider? Thx
- [x] Debian Bookworm
- [x] Debian Bullseye
- [x] Debian Buster
cool, all worked with insider version
But, need copy all 1f142a87df dir files to topdir(which have
VSCodium - Insiders.exe), otherwish show error log:Invalid file descriptor to ICU data received., and can't open vscodium-insider
Thx for your testing
But, need copy all 1f142a87df dir files to topdir(which have
VSCodium - Insiders.exe), otherwish show error log:Invalid file descriptor to ICU data received., and can't open vscodium-insider
Yep, I forgot to test on Windows... There are lots of changes (https://github.com/VSCodium/vscodium/pull/2618) for this release. On Windows, they are preparing for an appx package. It seems that 1.107 went without that structure while 1.108 does have it with extra files. I have to fix that.
Ok, Windows installers have been fixed.
@paradx Could you also test it (https://github.com/VSCodium/vscodium-insiders/releases/tag/1.107.18481-insider)? Thx
Same problem with version 1.106.37943 and Linux Mint 21.3. Downgraded to 1.103.15418.