Content:
A great feature of VS Code is the ability to connect to remote systems, and run code directly on them.
There are many advantages to doing this. You no longer need to worry about library version compatibility, as you’re running on the target system. Database connections can remain limited to localhost
. And you no longer have to load a single system with all of your dev libraries.
You can enable this feature by installing the appropriate plugins – which are developed by Microsoft themselves.
Unfortunately, a recent attempt to get this set up didn’t go to plan.
Node Not Found
Setting up VS Code Remote is designed to be simple. In this case, I was using the SSH Remote option, but there’s also an option for connecting to docker instances.
Once you’ve connected to the remote server, VS Code downloads software that runs on the client, which it uses to deploy the code you’re testing.
Setting this up on a Pi 4, I came across a the following error message.
Looking through the message log, I found this.
[14:43:38.053] > Server did not start successfully. Full server log at
/home/user/.vscode-server/.c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5.log >>>
[14:43:38.057] > /home/user/.vscode-server/bin/
c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5/bin/code-server: 12:
/home/user/.vscode-server/bin/
c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5/node: not found
The node executable that runs on the remote server is not found.
A check on the server shows the node file is there.
So what’s the issue?
Incorrect Architecture
It turns out, the issue is a simple one.
This particular Raspberry Pi is running the standard 32-bit version of Raspberry Pi OS. However, for increase database performance, it’s been updated to use the 64-bit kernel. This was achieved by adding
arm_64bit=1
to /boot/config.txt
.
This alters the output of uname -m
, to reflect that a 64-bit kernel is running.
$ uname -m
aarch64
Running the 64-bit kernel is enough to trigger VS Code to install a 64-bit version of the remote server application.
Unfortunate, as the userspace is still 32-bit, the application will not run. The OS doesn’t even recognise the 64-bit node application as an executable, hence the slightly misleading not found message.
An Easy Fix
Working around this requires first removing the VS Code data on the remote server. You can do this by running
rm -rf ~/.vscode-server
Next, comment out the arm_64bit=1
line in /boot/config.txt
.
#arm_64bit=1
Save the file, and reboot the system.
When the system has rebooted, confirm the change by running uname -m
again.
$ uname -m
armv7l
If the result is armv7l
, try setting up the VS Code remote server again.
[16:35:39.245] Remote server is listening on 41667
[16:35:39.245] Parsed server configuration: {
"serverConfiguration":{
"remoteListeningOn":{"port":41667},
"osReleaseId":"raspbian",
"arch":"armv7l",
"webUiAccessToken":"",
"sshAuthSock":"",
"tmpDir":"/run/user/1001",
"platform":"linux",
"connectionToken":"a1a11111-1111-11a1-111a-11aaa1a11a1a"
},
"downloadTime":4577,
"installTime":8750,
"serverStartTime":918,
"installUnpackCode":"success"
}
It should now run correctly. Note the arch is listed in the returned server configuration – which matches the uname -m
output.
Once this is complete, you can uncomment the line in /boot/config.txt
, and reboot the system, to switch back to the 64-bit kernel.
While this issue was encountered (and fixed) on a Raspberry Pi, it’s possible it will surface in any system using a different kernel and userspace architecture.