Vscode-remote-release: Problem with connecting to Raspberry 4

Created on 23 Jun 2020  路  11Comments  路  Source: microsoft/vscode-remote-release

Hi,

I try to connect to my raspberry pi4, it asking for platform and then for the password, but after all, I can't connect.

What is the problem?

[19:13:14.595] Log Level: 2
[19:13:14.599] [email protected]
[19:13:14.599] win32 x64
[19:13:14.600] SSH Resolver called for "ssh-remote+7b22686f73744e616d65223a223139322e3136382e312e313130222c2275736572223a22746164616d6f227d", attempt 1
[19:13:14.600] SSH Resolver called for host: [email protected]
[19:13:14.600] Setting up SSH remote "192.168.1.110"
[19:13:14.618] Using commit id "cd9ea6488829f560dc949a8b2fb789f3cdc05f5d" and quality "stable" for server
[19:13:14.619] Install and start server if needed
[19:13:18.549] Checking ssh with "ssh -V"
[19:13:18.616] > OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
[19:13:18.618] Running script with connection command: ssh -T -D 55355 [email protected] bash
[19:13:18.623] Terminal shell path: C:\Windows\System32\cmd.exe
[19:13:18.805] > 
[19:13:18.805] Got some output, clearing connection timeout
[19:13:19.017] > [email protected]'s password:
[19:13:19.017] Showing password prompt
[19:13:23.738] Got password response
[19:13:23.738] "install" wrote data to terminal: "***********"
[19:13:23.769] > 
> 
[19:13:24.207] > 019751043bce: running
> 
[19:13:24.233] > Acquiring lock on /home/roman/.vscode-server/bin/cd9ea6488829f560dc949a8b2fb789
> f3cdc05f5d/vscode-remote-lock.roman.cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
> \ln /home/roman/.vscode-server/bin/cd9ea6488829f560dc949a8b2fb789f3cdc05f5d/vsc
> ode-remote-lock.roman.cd9ea6488829f560dc949a8b2fb789f3cdc05f5d.target /home/tad
> amo/.vscode-server/bin/cd9ea6488829f560dc949a8b2fb789f3cdc05f5d/vscode-remote-lo
> ck.roman.cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
> 
[19:13:24.270] > Found existing installation at /home/roman/.vscode-server/bin/cd9ea6488829f560d
> c949a8b2fb789f3cdc05f5d...
> SHELL=/bin/bash
> PWD=/home/roman
> LOGNAME=roman
> XDG_SESSION_TYPE=tty
> HOME=/home/roman
> LANG=en_GB.UTF-8
> VSCODE_AGENT_FOLDER=/home/roman/.vscode-server
> SSH_CONNECTION=192.168.1.108 55359 192.168.1.110 22
> XDG_SESSION_CLASS=user
> USER=roman
> SHLVL=1
> XDG_SESSION_ID=c19
> XDG_RUNTIME_DIR=/run/user/1001
> SSH_CLIENT=192.168.1.108 55359 22
> PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
> MAIL=/var/mail/roman
> _=/usr/bin/printenv
> Starting server with command... /home/roman/.vscode-server/bin/cd9ea6488829f560
[19:13:24.296] > 
> dc949a8b2fb789f3cdc05f5d/server.sh --host=127.0.0.1 --enable-remote-auto-shutdow
> n  --port=0 &> "/home/roman/.vscode-server/.cd9ea6488829f560dc949a8b2fb789f3cdc
> 05f5d.log" < /dev/null
> Waiting for server log...
> 
[19:13:24.803] > Waiting for server log...
> 
[19:13:25.304] > Waiting for server log...
> 
[19:13:25.828] > Waiting for server log...
> 
[19:13:26.332] > Waiting for server log...
> 
[19:13:26.833] > Waiting for server log...
> 
[19:13:27.331] > Waiting for server log...
> 
[19:13:27.866] > Waiting for server log...
> 
[19:13:28.366] > 
> *
> * Reminder: You may only use this software with Visual Studio family products,
> * as described in the license (https://go.microsoft.com/fwlink/?linkid=2077057)
> *
> 
> Server did not start successfully. Full server log at /home/roman/.vscode-serve
> r/.cd9ea6488829f560dc949a8b2fb789f3cdc05f5d.log >>>
> /home/roman/.vscode-server/bin/cd9ea6488829f560dc949a8b2fb789f3cdc05f5d/server.
> sh: 12: /home/roman/.vscode-server/bin/cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
> /server.sh: /home/roman/.vscode-server/bin/cd9ea6488829f560dc949a8b2fb789f3cdc0
> 5f5d/node: not found
> <<< End of server log
> 019751043bce##32##
> 
[19:13:28.366] Received install output: 019751043bce##32##
[19:13:28.366] Resolver error: The VS Code Server failed to start
[19:13:28.369] ------



[19:13:28.820] "install" terminal command done
[19:13:28.820] Install terminal quit with output: 
[19:13:39.372] Picking SSH host
[19:13:52.242] Selected [email protected]
bug ssh

Most helpful comment

I had this too and found out that it was caused by "arm_64bit=1" in /boot/config.txt. That boots a 64bit kernel but it's otherwise still 32bit RaspiOS with 32bit userland. However, "uname -m" now reports aarch64 instead of armv7l, so Code probably downloads a 64bit version of node that it then can't start. That's the "node not found" error. Node is there, but it's the wrong version.

Work-around: rm -fr ~/.vscode-server/, comment out the arm_64bit=1 directive in config.txt, reboot, reconnect with Code which now loads a new 32bit version that works, re-enable arm_64bit, reboot, and it will still work.

All 11 comments

I also encountered this problem, it seems cause by the update?

I had this too and found out that it was caused by "arm_64bit=1" in /boot/config.txt. That boots a 64bit kernel but it's otherwise still 32bit RaspiOS with 32bit userland. However, "uname -m" now reports aarch64 instead of armv7l, so Code probably downloads a 64bit version of node that it then can't start. That's the "node not found" error. Node is there, but it's the wrong version.

Work-around: rm -fr ~/.vscode-server/, comment out the arm_64bit=1 directive in config.txt, reboot, reconnect with Code which now loads a new 32bit version that works, re-enable arm_64bit, reboot, and it will still work.

Another possible work-around, if you have multiple Pi4s, is to copy the whole ~/.vscode-server directory (e.g. using rsync -a) from a working installation to a Pi4 that's running the 64bit kernel. I did this for a Pi4 which I didn't want to reboot twice, and it worked.

Work-around: rm -fr ~/.vscode-server/, comment out the arm_64bit=1 directive in config.txt, reboot, reconnect with Code which now loads a new 32bit version that works, re-enable arm_64bit, reboot, and it will still work.

That workaround fixed the issue for me. Thanks @ednl!

Does anyone know, is there a different command I should be running other than uname to check which bitness of server should run?

I just asked on their forum. For now, I can only think of a hard-coded secondary check:

ARCH=$(uname -m)
[ "$ARCH" = "aarch64" ] && grep 'arm_64bit=1' /boot/config.txt && ARCH=armv7l

Edit: their suggestion was to use "file /bin/ls". E.g. "file -b /bin/ls | cut -d' ' -f2 | cut -d- -f1" would give either "32" or "64".

Edit2: that first test "ARCH=" etc. that I came up with would be incorrect on RaspiOS 64-bit which is in beta at the moment, because that too has "arm_64bit=1" in /boot/config.txt but there it does mean that the whole install is 64-bit ...

That's a good suggestion. I am actually more inclined to use the check with /boot/config.txt so it would be scoped to this scenario. The output of file doesn't look like it's meant to be parsed. And it's very different between linux and mac. Is this config always in /boot/config.txt for Raspberry Pi?

Is this config always in /boot/config.txt for Raspberry Pi?

Yes. There has to be a FAT (-32) /boot partition for the GPU to start the process, and that's the only place that config.txt can go, and that's the only place that the setting can go.

And you're right that 'file' output does not seem to be made to be parseable. On the other hand, it is now possible to define different sections in config.txt for different machines, so just the presence of the directive is no guarantee. Also, I suppose that the directive can be overridden by the opposite "arm_64bit=0". So really, to be 100% sure you would need to grammatically parse config.txt ...

In that sense, grepping "file /bin/ls" is both easier and more deterministic. I see that "file -b" (b for brief) gives the same second field on Debian, Raspbian, Ubuntu and MacOS: either "32-bit" or "64-bit". So, those two cuts in my example would give the same result.

Thanks for checking that. I think that's a better route than understanding what's in config.txt. I am still nervous about assuming that anything will hold true over everyone's machine but I'll keep thinking about it.

I had this too and found out that it was caused by "arm_64bit=1" in /boot/config.txt. That boots a 64bit kernel but it's otherwise still 32bit RaspiOS with 32bit userland. However, "uname -m" now reports aarch64 instead of armv7l, so Code probably downloads a 64bit version of node that it then can't start. That's the "node not found" error. Node is there, but it's the wrong version.

Work-around: rm -fr ~/.vscode-server/, comment out the arm_64bit=1 directive in config.txt, reboot, reconnect with Code which now loads a new 32bit version that works, re-enable arm_64bit, reboot, and it will still work.

That's great! Which trouble me so long, thanks!

Including Raspberry Pi 3 that also supports a 64-bit kernel.
The workarounds (e.g. https://github.com/microsoft/vscode-remote-release/issues/3248#issuecomment-667713057) stated here work on Pi 3 platform too.

Was this page helpful?
0 / 5 - 0 ratings