Support for connecting to Apple Silicon/M1/ARM64 remote

[smokris]

When I use Visual Studio Code 1.51.1 running on macOS 11.0.1 x86_64 and attempt to connect using remote-ssh 0.56.0 to a macOS 11.0.1 arm64 system, the VS Code Server fails to start on the remote system:

[13:47:19.278] > /Users/…/.vscode-server/bin/e5a624b788d92b8d34d1392e4c4d9789406efe8f/server.sh: line 12: /Users/…/.vscode-server/bin/e5a624b788d92b8d34d1392e4c4d9789406efe8f/node: Bad CPU type in executable

That binary is x86_64 only, whereas (in order for it to work natively / without needing the Rosetta translation layer) it should be arm64 or "Universal" (x86_64 + arm64).

$ file .vscode-server/bin/e5a624b788d92b8d34d1392e4c4d9789406efe8f/node
.vscode-server/bin/e5a624b788d92b8d34d1392e4c4d9789406efe8f/node: Mach-O 64-bit executable x86_64

[roblourens]

@joaomoreno are we building the server for this yet? I don't see the mac arm build on our builds page

[joaomoreno]

@deepak1556 Is the right person to ping.

[gorilla-1]

I have the same issue with my WSL at VS Code
e5a624b788d92b8d34d1392e4c4d9789406efe8f: -c: line 0: unexpected EOF while looking for matching

[deepak1556]

Yeah I had left this out for the exploration release, definitely something to add. Thanks for opening the issue!

[deepak1556]

Since we download prebuilt node binaries for the remote, and there is no arm64 version available yet. This feature cannot move forward until then.

[richiksc]

Is this feature required to move forward with microsoft/vscode#106770, and does it prevent the exploration build from being promoted to Insiders? Just curious.

[deepak1556]

Not it doesn't. Once we have vscode stable 1.52, the next insiders following it will contain mac arm builds too.

[johnwiseheart]

Definitely excited about this, since I believe its the final thing left to get my corporate set-up working on a new M1 mac.

For context, we spin up docker containers on our local machines and attach to them - so on M1 mac's, the docker containers are running ARM Alpine, and seeing the error Alpine Linux is not supported on the hardware architecture 'aarch64' of the container. when attaching to them using vscode remote - containers.

[rickardp]

What is the status on the ARM64/Alpine support?

The current workaround for me is to pin every Docker image reference to the SHA256 of the X64 version. I believe there is no setting to force the x64 arch by default, at least I couldn't find one, so this starts to get a little messy.

[johnwiseheart]

@deepak1556 wondering if you have any update here? Would love to start using my M1 mac, but this is still blocking me from the workflows required by my company.

[ascorbic]

@johnwiseheart Have you tried it? I'm using an M1 as a remote and it works fine.

[xlc]

The only issue I have is that shell is launched by x86 process so I have to run a $ arch -arm64e bash -l to start arm64 shell

[johnwiseheart]

@ascorbic I still see the error Alpine Linux is not supported on the hardware architecture 'aarch64' of the container. - are you using Alpine?

[ascorbic]

@johnwiseheart Ah I missed that. I'm talking about the Mac M1

[johnwiseheart]

Me too! My setup involves running docker containers locally (on the M1) and using the remotes extension to code inside of the containers. So the container host is the M1 - but from what I can tell maybe it's just that Alpine isn't supported on ARM devices?

[johnwiseheart]

For what it's worth, changing to a non-alpine distro like Ubuntu fixes this, but unfortunately because the infrastructure is out side of my control that change isnt possible for me.

[ascorbic]

Ah, ok. My setup is a headless M1 (running Mac OS) as a compilation server. I've successfully connected to it from Intel and ARM Macs.

[adamreis]

I'm running into the same error as @johnwiseheart when trying to open a "remote" (running locally) Alpine ARM container from my M1 mac.

[NSExceptional]

So to be clear, we have official macOS ARM64 support working? And we're just waiting on Alpine?

[johnwiseheart]

@NSExceptional from what I understand, the remaining issue is still a vscode issue - since Alpine works on intel macs, but still not on ARM. But I may be wrong - if I do misunderstand, would really appreciate a heads up so I can redirect my issues.

[ohsayan]

Sad, Connection error: Unauthorized client refused still occurs whenever you compile an ARM64 Node v14 with the latest VSCode and try to swap out the binaries.

I precisely did that; refer to this comment

[deepak1556]

version 1.56 of vs code is out now, any eta on when a fix can be done?

Depends on release of 14.17.0 nodejs/node#38507. We then need to get the change in electron and make a separate release before we can start any work. So no eta at the moment.

Connection error: Unauthorized client refused still occurs whenever you compile an ARM64 Node v14 with the latest VSCode and try to swap out the binaries.

You would also need to recompile the native modules that are bundled into the server for the arm architecture.

[Absolucy]

Ok, so I swapped out the node binary with an ARM64 one, edited one of the JS files (remoteExtensionHostAgent.js) to patch out the "Unauthorized client refused" error, and recompiled node-pty.

Basic functionality works, but extensions and the terminal are broken.

[lezuber]

Any update here? nodejs/node#38507 seems to be released?

[deepak1556]

nodejs doesn't seem to release arm binaries for 14.x version nodejs/node#37309 (comment). This has to wait until vscode desktop adopts node 16.x which will be with electron 14 update.

[youknowone]

I tried x64 to arm64 connect via remote-ssh and it was successful. Is this now resolved?

[CharlesJones88]

I tried x64 to arm64 connect via remote-ssh and it was successful. Is this now resolved?

No it looks like vs code has to upgrade to electron 15 when that gets released, then they will start looking at a fix

[astrowonk]

I also tried from an intel mac to an m1 mac as the host via remote-ssh and it was successful. But the M1 Mac is running the server (Node) with Rosetta.

[fabge]

When Remote SSHing from an M1 Macbook Air to an M1 Mac Mini I experience the same issue.
The whole thing is running under Rosetta. Is there any way to fix this?

[mikehardy]

@fabge if I understand correctly it won't be fixed completely until VSCode updates to a newer version of node under the covers, which won't happen until it is forward-ported to a newer version of Electron, which requires a bunch of other work, so maybe not for a while.

However, this workaround does the trick for me after I remote ssh in - I have this set in my bash aliases file as arm64 and I just run it after the ssh connects: arch -arm64e bash -l - now your shell is arm64-native

[Mellbourn]

@alexdima does closing this indicate that it is fixed? Remote-SSH to Apple Silicon still does not work for me.

[Absolucy]

@Mellbourn I assume it'll work in the next major update.

[JacksonKearl]

@alexdima On the latest insiders when I try to remote-ssh to my M1 machine I still see uname -m return x86_64.

I do see some indication of arm64 in the logs:

[17:47:19.149] Remote server is listening on 59484
[17:47:19.149] Parsed server configuration: {"serverConfiguration":{"remoteListeningOn":{"port":59484},"osReleaseId":"Darwin","arch":"arm64","webUiAccessToken":"","sshAuthSock":"","display":"","tmpDir":"/tmp","platform":"macOS","connectionToken":"1111aa11-1a11-1a11-1111-1a11a11a1111"},"downloadTime":8000,"installTime":1000,"serverStartTime":3000,"installUnpackCode":"success"}
[17:47:19.150] ** Note: Support for architecture "arm64" is in preview **

[alexdima]

Here are the steps:

• From VS Code Insiders, switch to Remote - SSH Pre-Release
• (my version is Remote - SSH v0.77.2022032415)
• (if you are on an arm64 mac, enable System Preferences > Sharing > Remote Login)
• connect to localhost via SSH
• in the integrated terminal, uname -m should print arm64

Note: If you have used a specific VS Code Insiders version with Remote - SSH stable, then the x64 version of vscode-server has been downloaded and is cached at $HOME/.vscode-server-insiders/bin/<commit>. To get the Remote - SSH Pre-Release to download the arm64 version it is necessary to delete the cache and kill all running vscode server processes.