microsoft
Support ssh to IBM LinuxOne (Red Hat Enterprise)
- VSCode Version: Insider 1.36.0
- Local OS Version: macOS High Sierra 10.13.4
- Remote OS Version: Red Hat Enterprise Linux Server release 7.6 on IBM LinuxOne
- Remote Extension/Connection Type: SSH
Steps to Reproduce:
- Connect to remote system
- "Can't connect to linux: unreachable or note Linux x86?64 (Linux s390x)"
Does this issue occur when you try this locally?: Yes Does this issue occur when you try this locally and all extensions are disabled?: Yes
Using the VScode insider V1.39.0 insider Attempting to connect to a RedHat V7.6 server running on s390x. Get the following error upon connection. Add me to the list requesting this feature.
Hi Guys, i am trying this on Ubuntu 18.04 S390x, same Problem. Can you please add architecture s390x to the list of supported architectures for the vscode ssh extention? If you need access to a Linux running on S390x and you do not have access to an IBM Mainframe or LinuxONE System you could use the wonderful hercules emulator. z/Linux under hercules is not the fastest experience but it does work beautifully. Be aware that as of this writing Ubuntu 20.04 does not work under hercules though. You need to use 18.04. You can download an installation image from here. There are some great youtube videos on how to set this up, for example this one and a more specific video about networking issues can be found here.
thanks in advance and greetings from germany
Actually, if you need to access a real Linux on Z (s390x) system, you can request a VM from LinuxONE Community Cloud for developers. You can sign up from here.
I'll add my request for an s390x port of the VSCode Remote Server. I'd do it myself if the code was open source.
FWIW, I'll be running my net-facing server on Ubuntu on Hercules on a Raspberry Pi, just because. Once upon a time, I was the lead maintainer and project manager for Hercules.
I was able to get this working with selective tweaks to the installed .vscode-server and a wrapper around uname. (main issue is the native executable for node and the native shared objects for node-pty and spdlog. I understand the need to control for support purposes, but would it be possible to add an extension point here for 3rd party support of "unsupported" architectures?
uname.txt
I was able to get this working with selective tweaks to the installed .vscode-server and a wrapper around uname. (main issue is the native executable for node and the native shared objects for node-pty and spdlog. I understand the need to control for support purposes, but would it be possible to add an extension point here for 3rd party support of "unsupported" architectures? uname.txt
I was able to do similar and those x86_64 ELF objects in node_modules were rebuilt and node v14 installed. However, things still don't start up when I connect. I get back: Connection error: Unauthorized client refused.
I was able to do similar and those x86_64 ELF objects in node_modules were rebuilt and node v14 installed. However, things still don't start up when I connect. I get back:
Connection error: Unauthorized client refused.
We had to tweak the out/vs/server/remoteExtensionHostAgent.js file to get past this. (essentially bypass the validation). Additionally ended up installing/setting up qemu to run cross-architecture executables since a number of the remote extension plugins have the same issue (see https://ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc/)
Is there a tool to unpack/reformat that code (the .js file you referenced)? It's almost unreadable.
We have a working dotnet command for s390x working and I rebuilt several of node modules so what other plug-ins did you discover are problematic?
Thanks for the assistance... Neale
I use js-beautify (npm install -g js-beautify) to "un-uglify" the js source.
cpptools was one example of a plugin that was problematic.
Found one and was able to bypass the validation problem but now it complains about a reconnection token.
@DanGritter It appears there's been a lot of changes. There's a node module called vsda.node ("VS Code debug handshake module") that does a lot of work that just comes as an ELF binary.
try {
const oe = J.__$__nodeRequire("vsda");
j = new oe.validator, re = new oe.signer
} catch {}
let x;
(function(oe) {
oe[oe.WaitingForAuth = 0] = "WaitingForAuth", oe[oe.WaitingForConnectionType = 1] = "WaitingForConnectionType", oe[oe.Done = 2] = "Done", oe[oe.Error = 3] = "Error"
})(x || (x = {}));
The code:
node_modules/vsda:
build index.js package.json test.js
node_modules/vsda/build/Release:
vsda.node
The executable appears to be a C++ program doing signing, validating, and handshaking.
+1 Would make things much easier for the whole IBM Firmware development team and a lot of other people.
There has been plenty of past requests and offers to contribute to this feature. I understand that this team is busy with their priorities; we would appreciate a response, update, or path forward with contributing to this feature since we want a seamless experience with us VS Code.
