node in vscodium-reh-linux-x64-1.82.0.23250 executed on Alpine Linux will report "node: fcntl64: symbol not found"

[python-and-fiction]

vscodium-reh: https://github.com/VSCodium/vscodium/releases/download/1.82.0.23250/vscodium-reh-linux-x64-1.82.0.23250.tar.gz vscode server: https://update.code.visualstudio.com/commit:8b617bd08fd9e3fc94d14adb8d358b56e3f72314/server-linux-x64/stable

remote machine: Alpine Linux edge,i have installed gcompat which cans make Alpine Linux runs glibc execute file.

when i update vscode and vscodium to 1.82.0,vscode-server works well,but vscodium-reh doesn't work well as expect. I try to execute node in vscodium-reh,it reports "node: fcntl64: symbol not found".When i do the same on Debian 12 machine,it works well. Maybe vscode-server's node is different from vscodium-reh's. I just code simple Python programs,this should work as well as 1.81.1.

[daiyam]

vscode has binary for alpine (https://github.com/microsoft/vscode/blob/main/build/azure-pipelines/alpine/product-build-alpine.yml)

[GitMensch]

@daiyam So vscodium needs one for alpine (musl), too?

Note that the issue isn't Alpine in general but (very likely) musl that doesn't include fcntl64 and the "gcompat" isn't either correctly installed/configured or doesn't work. Apart from fcntl64 [musl just has this as a define, not as a function!] backtrace and other glibc symbols are missing; so @python-and-fiction please check your setup.

[daiyam]

Other that the compactness and the use of musl, I didn't know anything about Alpine

So vscodium needs one for alpine (musl), too?

Yeah, specially for reh.

[python-and-fiction]

@daiyam So vscodium needs one for alpine (musl), too?

Note that the issue isn't Alpine in general but (very likely) musl that doesn't include fcntl64 and the "gcompat" isn't either correctly installed/configured or doesn't work. Apart from fcntl64 [musl just has this as a define, not as a function!] backtrace and other glibc symbols are missing; so @python-and-fiction please check your setup.

I am just a normal user of Alpine Linux,can't solve all problems. But i know that the reh of 1.81.1 works well,and the reh of 1.82.0 doesn't. I just am curious about the difference between 1.81.1 and 1.82.0. Although there are some symbol errors,I can code python program remotely which is on Alpine.And python program works well in python's venv. Python is a cross-platform language,Alpine Linux becomes more and more popularly. We can fix bug in future,and i will use VSCode to do this temporarily.I hope that VSCodium works as well as VSCode on Alpine Linux. Thanks.

[GitMensch]

I guess this is rooted in the change to node_v18 which has different dependencies in glibc than the previous node_v16 which was used up to 1.18.1. See https://github.com/VSCodium/vscodium/issues/1629 for more discussion on that.

[GitMensch]

@python-and-fiction As you have vscode-reh installed - please run ldd -v on the node installation of both vscode-server 1.82 and vscodium-reh 18.2 and post the output.

[python-and-fiction]

@python-and-fiction As you have vscode-reh installed - please run ldd -v on the node installation of both vscode-server 1.82 and vscodium-reh 18.2 and post the output.

sorry,Alpine's ldd doesn't support option -v. Maybe you can download both of files via following urls. And compare them vscodium-reh: https://github.com/VSCodium/vscodium/releases/download/1.82.0.23250/vscodium-reh-linux-x64-1.82.0.23250.tar.gz vscode server: https://update.code.visualstudio.com/commit:8b617bd08fd9e3fc94d14adb8d358b56e3f72314/server-linux-x64/stable

[GitMensch]

As expected, the node distributed by MS is not the official binary, but rebuilt.

Interestingly it has the exact same dependency version information as the official unofficial glibc-2.17 built of node https://unofficial-builds.nodejs.org/download/release/v18.16.1/node-v18.16.1-linux-x64-glibc-217.tar.xz.

Also interesting is that there's an official unofficial musl version - https://unofficial-builds.nodejs.org/download/release/v18.15.0/node-v18.15.0-linux-x64-musl.tar.xz, using this for a special musl version of vscodium-reh sounds interesting, too.

@python-and-fiction: as you already have vscodium-reh installed you may want to try to overwrite the included node with the musl version (it is the same version and your vscodium-reh is broken already) - if that works then it is likely better than using VSC ;-)

[python-and-fiction]

@GitMensch Wonderful, I'd noted that. Thanks a lot.

[python-and-fiction]

As expected, the node distributed by MS is not the official binary, but rebuilt.

Interestingly it has the exact same dependency version information as the official unofficial glibc-2.17 built of node https://unofficial-builds.nodejs.org/download/release/v18.16.1/node-v18.16.1-linux-x64-glibc-217.tar.xz.

Also interesting is that there's an official unofficial musl version - https://unofficial-builds.nodejs.org/download/release/v18.15.0/node-v18.15.0-linux-x64-musl.tar.xz, using this for a special musl version of vscodium-reh sounds interesting, too.

@python-and-fiction: as you already have vscodium-reh installed you may want to try to overwrite the included node with the musl version (it is the same version and your vscodium-reh is broken already) - if that works then it is likely better than using VSC ;-)

GitMensch's answer is perfect.

[GitMensch]

@python-and-fiction So overwriting the distributed node with the same version from the unofficial official musl build allows you to run vscodium-reh?

In this case @daiyam: Do you see an option to distribute a musl version? I guess this could be the "alpine" version and it would likely work out of the box. ... but of course this also would have to be downloaded with the remote extension, not sure if that would be possible without manually adjusting the URL template there.

[python-and-fiction]

@python-and-fiction So overwriting the distributed node with the same version from the unofficial official musl build allows you to run vscodium-reh?

In this case @daiyam: Do you see an option to distribute a musl version? I guess this could be the "alpine" version and it would likely work out of the box. ... but of course this also would have to be downloaded with the remote extension, not sure if that would be possible without manually adjusting the URL template there.

Yes,VSCodium 1.82.0 is working with Alpine now. I think do same as MS maybe it's better? or supply musl version reh for Alpine's user, they can replace glibc version reh manully with musl version reh.

[jeanp413]

I've got a few reports related to this now, all users using ubuntu 18 are affected

[GitMensch]

Just rechecked: To run on Ubuntu 18 and RHEL7 the following does work.

And the workaround is still the right approach - using the correct node version; for 1.84.2 that's still 18.15.

For Ubuntu 18 or RHEL7 there is no 18.15 with glibc-217 available, so one has to upgrade it to https://unofficial-builds.nodejs.org/download/release/v18.16.1/node-v18.16.1-linux-x64-glibc-217.tar.xz

I've cp -prv 'd bin/node and lib/node_modules to the codium-server directory.

[eduncan911]

Ditto. Was connecting to Ubuntu 18.04 LTS machines in the past, but now borked.

$ cat /home/user/.vscodium-server/.<snip>.log
/home/user/.vscodium-server/bin/<snip>/node: 
/lib/aarch64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found
(required by /home/user/.vscodium-server/bin/<snip>/node)

$ ldd --version -v
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27

$ sudo apt search codium
Sorting... Done
Full Text Search... Done
codium/unknown,now 1.85.1.23348 amd64 [installed]
  Code editing. Redefined.

$ cat /etc/apt/sources.list.d/vscodium.list 
deb [ signed-by=/usr/share/keyrings/vscodium-archive-keyring.gpg ] https://download.vscodium.com/debs vscodium main

• Pop_OS 22.04 (e.g. Ubuntu 22.04).
• Via commandline.
• VSCodium 1.85.1 (no ugprade availabel)

[eduncan911]

Just rechecked: To run on Ubuntu 18 and RHEL7 the following does work.

And the workaround is still the right approach - using the correct node version; for 1.84.2 that's still 18.15. For Ubuntu 18 or RHEL7 there is no 18.15 with glibc-217 available, so one has to upgrade it to https://unofficial-builds.nodejs.org/download/release/v18.16.1/node-v18.16.1-linux-x64-glibc-217.tar.xz

I've cp -prv 'd bin/node and lib/node_modules to the codium-server directory.

Would you be able to elaborate on the instructions? Just replace the node binary and all lib/node_modules?

[GitMensch]

Please let's keep this issue to Alpine, the glibc versioning issue you see is tracked at #1629, which now also contains a link to the upstream issue (support was explicit dropped upstream, because it was dropped in Electron). The upstream issue also has elaborated instructions.

[daiyam]

The alpine's REH is available at https://github.com/VSCodium/vscodium-insiders/releases/tag/1.87.0.24058-insider But the extension will need some changes:

• I get the error ash: bash: not found
• for the url, $PLATFORM must be alpine

[GitMensch]

The alpine's REH is available

Does that mean the REH is expected to just run - or doe we still need the compat packages as per open-remote-ssh README?

I guess you mean that you get an error with that extension - please check if https://github.com/jeanp413/open-remote-ssh/pull/142 solves that (untested!).

[daiyam]

I think your PR should fix my second point.

For the first one, the "setup" script expects bash. It seems that Alpine uses ash as its default shell ( bash isn't installed by default). Should we require bash to simplify the extension? @jeanp413, what do you think? Currently, the "setup" script is only available in bash or powershell.

[GitMensch]

For the bash -c call - can we use $SHELL -c instead? If conn.exec executes code with the default shell, then this should work. Note that the second commit of this PR currently uses ash if bash is not found - but the $SHELL would obviously be better.

[daiyam]

No, bash will be a requirement as libstdc++ and procps.

I can't make it work, the socks tunnel doesn't seem to going up, no error...

[HoboDev]

@daiyam try changing the sshd config and set AllowTcpForwarding to yes

I always received an error for the Websocket and when changing something else I figured out that this was an issue. In my repeated tests I used a fresh alpine linux install and only installed bash but none of the packages in the open remote ssh readme. Worked fine after overwriting the reh with the alpine version.

I'm sure even the bash dependency could be removed (for linux) by making the script posix compliant but installing bash isn't too bad.

[daiyam]

@HoboDev Thx AllowTcpForwarding yes was the answer.