Cannot install version 1.81 on RHEL 7.9 (or Ubuntu 18)
renatobellotti opened this issue ยท 34 comments
I currently have version 1.64.2
(I know, very old) installed and cannot install 1.81
because of the following errors:
$ sudo yum install ./codium-1.81.1.23222-el7.x86_64.rpm
Loaded plugins: langpacks, search-disabled-repos
Examining ./codium-1.81.1.23222-el7.x86_64.rpm: codium-1.81.1.23222-el7.x86_64
Marking ./codium-1.81.1.23222-el7.x86_64.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package codium.x86_64 0:1.81.1.23222-el7 will be installed
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: codium-1.81.1.23222-el7.x86_64
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package: codium-1.81.1.23222-el7.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: codium-1.81.1.23222-el7.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: codium-1.81.1.23222-el7.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) for package: codium-1.81.1.23222-el7.x86_64
--> Finished Dependency Resolution
Error: Package: codium-1.81.1.23222-el7.x86_64 (/codium-1.81.1.23222-el7.x86_64)
Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit)
Error: Package: codium-1.81.1.23222-el7.x86_64 (/codium-1.81.1.23222-el7.x86_64)
Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit)
Error: Package: codium-1.81.1.23222-el7.x86_64 (/codium-1.81.1.23222-el7.x86_64)
Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
Error: Package: codium-1.81.1.23222-el7.x86_64 (/codium-1.81.1.23222-el7.x86_64)
Requires: libstdc++.so.6(GLIBCXX_3.4.22)(64bit)
Error: Package: codium-1.81.1.23222-el7.x86_64 (/codium-1.81.1.23222-el7.x86_64)
Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
How can I solve this problem?
Hi,
I have a similar error when trying to install vscodium-server (from vscodium v1.82.0) using open-remote-ssh on a CentOS 7.9 remote machine. The install fails and reports lacking packages:
/home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node: /usr/lib64/libm.so.6:
version `GLIBC_2.27' not found (required by /home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node)
/home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node: /usr/lib64/libc.so.6:
version `GLIBC_2.25' not found (required by /home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node)
/home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node: /usr/lib64/libc.so.6:
version `GLIBC_2.28' not found (required by /home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node)
/home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node: /usr/lib64/libstdc++.so.6:
version `CXXABI_1.3.9' not found (required by /home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node)
/home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node: /usr/lib64/libstdc++.so.6:
version `GLIBCXX_3.4.20' not found (required by /home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node)
/home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node: /usr/lib64/libstdc++.so.6:
version `GLIBCXX_3.4.21' not found (required by /home/XXX/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/node)
I checked glibc version is 2.17. Is there a chance to get it working?
Thanks in advance
I tried some tricks listed here but none worked.
While that doesn't solve the issue (note VSCodium may have higher dependencies than vscodium-reh) I can share that VSCodium 1.77 definitely works on RHEL7/CentOS7, so until the issue is checked you may want to use this instead.
I can confirm that VSCodium 1.77.3 works fine on CentOS7, thanks
I can't re-find the source... but I've read that CentOS7 won't be supported anymore.
1.82
ships with node-v18
which:
- Prebuilt binaries for Linux are now built on Red Hat Enterprise Linux (RHEL) 8 and are compatible with Linux distributions based on glibc 2.28 or later, for example, Debian 10, RHEL 8, Ubuntu 20.04. src
MS might do extra stuff with the new build. Any PR is welcome ๐
Which version is the last one that ships with a previous version of node?
Would it be possible to use a new vscode with a system installed node instead?
Which version is the last one that ships with a previous version of node?
1.81.x
Would it be possible to use a new vscode with a system installed node instead?
No, their version need to match.
Which version is the last one that ships with a previous version of node?
1.81.x
This issue says that 1.81 wasn't usable with RHEL7 either, so this still seems to be not working.
Can someone please outline the node versions used with vscode 1.77 to 1.82 (we already know 1.77.1 using v16.14.2
and 1.81.1 using v16.17.1
and 1.82.0 using v18.15.0
)?
In any case only node 18 has an announcement about using RHEL8 and a comment of
From the trusty https://en.wikipedia.org/wiki/Glibc#Version_history table, switching to RHEL8 would give us a minimum glibc of 2.28 which ships with Ubuntu 18.10, Debian 10 (Buster), and Fedora 29. The only concern there is that it's later than 18.04, so we're ruling out those systems. But I think that's reasonable for a new release of Node.js - 18.04 users will either need to stick to older Node.js or compile themselves using a newer toolchain from ppa.
@daiyam It does seem reasonable to use an alternative node.js, as I understand it there "unofficial official" builds which support older glibc versions, for example https://unofficial-builds.nodejs.org/download/release/v18.17.1/node-v18.17.1-linux-x64-glibc-217.tar.xz (first one is 18.16.0)
It seems this would be enough to support those old environments, no?
Note: the node version distributed with https://update.code.visualstudio.com/commit:8b617bd08fd9e3fc94d14adb8d358b56e3f72314/server-linux-x64/stable 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
It seems reasonable to switch to that instead of the "official offical node_v18" - at least for distribution.
While that doesn't solve the issue (note VSCodium may have higher dependencies than vscodium-reh) I can share that VSCodium 1.77 definitely works on RHEL7/CentOS7, so until the issue is checked you may want to use this instead.
Thanks for the hint! Unfortunately, I get an error message for version 1.77.3.23102
:
$ sudo yum install ./codium-1.77.3.23102-el7.x86_64.rpm
Loaded plugins: langpacks, search-disabled-repos
Examining ./codium-1.77.3.23102-el7.x86_64.rpm: codium-1.77.3.23102-el7.x86_64
Marking ./codium-1.77.3.23102-el7.x86_64.rpm as an update to codium-1.64.2-1644538630.el7.x86_64
Resolving Dependencies
--> Running transaction check
---> Package codium.x86_64 0:1.64.2-1644538630.el7 will be updated
---> Package codium.x86_64 0:1.77.3.23102-el7 will be an update
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: codium-1.77.3.23102-el7.x86_64
--> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package: codium-1.77.3.23102-el7.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: codium-1.77.3.23102-el7.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: codium-1.77.3.23102-el7.x86_64
--> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) for package: codium-1.77.3.23102-el7.x86_64
--> Finished Dependency Resolution
Error: Package: codium-1.77.3.23102-el7.x86_64 (/codium-1.77.3.23102-el7.x86_64)
Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit)
Error: Package: codium-1.77.3.23102-el7.x86_64 (/codium-1.77.3.23102-el7.x86_64)
Requires: libstdc++.so.6(GLIBCXX_3.4.22)(64bit)
Error: Package: codium-1.77.3.23102-el7.x86_64 (/codium-1.77.3.23102-el7.x86_64)
Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit)
Error: Package: codium-1.77.3.23102-el7.x86_64 (/codium-1.77.3.23102-el7.x86_64)
Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit)
Error: Package: codium-1.77.3.23102-el7.x86_64 (/codium-1.77.3.23102-el7.x86_64)
Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Here are some more details about my OS version:
$ lsb_release -a
LSB Version: :core-4.1-amd64:core-4.1-noarch
Distributor ID: RedHatEnterpriseServer
Description: Red Hat Enterprise Linux Server release 7.9 (Maipo)
Release: 7.9
Codename: Maipo
ping @daiyam
It does seem reasonable to use an alternative node.js
as I understand it, there are "unofficial official" builds which support older glibc versions, for example https://unofficial-builds.nodejs.org/download/release/v18.17.1/node-v18.17.1-linux-x64-glibc-217.tar.xz (first one is 18.16.0)It seems this would be enough to support those old environments, no?
Should we use the linux-x64-glibc-217 node versions for our builds?
@daiyam as GitMensch mentioned above can we switch to use the custom node to build vscodium so it can support old linux version as vscode does ?
I took a look and seems we are using nvm. Unfortunately it does not official support the unofficial build of node, but maybe the below workaround can help. Since I'm not familiar with our build pipeline so I was not able to make the pr
I used 18.17.5
just as a random version name, since it need to follow the format to pass the validation phase of nvm
wget https://unofficial-builds.nodejs.org/download/release/v18.17.1/node-v18.17.1-linux-x64-glibc-217.tar.xz
tar -xf node-v18.17.1-linux-x64-glibc-217.tar.xz
mv node-v18.17.1-linux-x64-glibc-217 ~/.nvm/versions/node/v18.17.5
nvm use 18.17.5
I will look into it.
Note that official vscode will drop support too starting from the next release 1.86 microsoft/vscode#201129
Could we get @paulcarroty to update the aptitude repo (Ubuntu) to include previous versions? I do not have a gitlab account to login and make the comment. VSCodium Ubuntu installation repo is published over there:
https://gitlab.com/paulcarroty/vscodium-deb-rpm-repo
Seems the current launchpad only lists the latest version, and no previous versions to install (which would have made it super easy to downgrade).
$ sudo apt policy codium
codium:
Installed: (none)
Candidate: 1.85.1.23348
Version table:
1.85.1.23348 500
500 https://download.vscodium.com/debs vscodium/main amd64 Packages
If we could get him to re-publish 1.77, then the user would only need to do:
$ sudo apt install codium=1.77
Most other packages include previous versions:
brave-browser:
Installed: 1.61.114
Candidate: 1.61.114
Version table:
*** 1.61.114 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
100 /var/lib/dpkg/status
1.61.109 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
1.61.104 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
1.61.101 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
1.61.100 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
1.60.125 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
1.60.118 500
500 https://brave-browser-apt-release.s3.brave.com stable/main amd64 Packages
Here's the flatpak
instructions to downgrade to 1.77:
$ sudo apt purge codium
...
$ rm -rf ~/.config/VSCodium
...and then search and use the commit for 1.77:
$ flatpak remote-info --log flathub com.vscodium.codium | grep -B1 -A1 "1\.77"
Commit: a211d057d4e557d3330e442be3a02f55221bf9dea3340f0266d9cc9ba6ab4c19
Subject: :tada: Upgrade VSCodium to v1.77.3.23102 (ca8a856b)
Date: 2023-04-12 19:14:45 +0000
--
Commit: 02ea8d939e66661031a4ee4020d048748b3bb6baecce98b6ef3da9d8f9a0586e
Subject: :tada: Upgrade VSCodium to v1.77.2.23101 (d65bccf7)
Date: 2023-04-12 16:09:37 +0000
--
Commit: 9cab0f85b194c8dadaf892cb0af61234629741536771059d814f804a0c8ee17d
Subject: :tada: Upgrade VSCodium to v1.77.1.23095 (85e3ba57)
Date: 2023-04-05 20:02:30 +0000
--
Commit: e99f23749b4717c8b65a4bd41de33f3d689f6330fdcca6ebe961e7b3350454ea
Subject: :tada: Upgrade VSCodium to v1.77.0.23095 (26476e94)
Date: 2023-04-05 19:02:57 +0000
flatpak requires you install first, and then "upgrade" to that previous specific version (commit)...
$ flatpak install codium
$ flatpak upgrade --commit=a211d057d4e557d3330e442be3a02f55221bf9dea3340f0266d9cc9ba6ab4c19 com.vscodium.codium
@eduncan911 Gitlab Pages still has hard 1 GB size limit, open to resettlement ideas.
@eduncan911 Gitlab Pages still has hard 1 GB size limit, open to resettlement ideas.
GitHub has unlimited total attachment sizes for Releases (limited to 2GB per file), unlimited number of files, and unlimited number of Releases. You can directly link to github raw release download url for any direct downloads. I do this for a number of other projects.
Quoted straight from the docs:
Distributing large binaries
If you need to distribute large files within your repository, you can create releases on GitHub.com. Releases allow you to package software, release notes, and links to binary files, for other people to use. For more information, visit "About releases."We don't limit the total size of the binary files in the release or the bandwidth used to deliver them. However, each individual file must be smaller than 2 GiB.
If you want to keep things at GitLab, that's fine. Someone with Owner rights to this Github Org can setup a new repo that clones yours from GitLab. Then, in /VSCodium/
org version will have an additional directory commit for .github
actions. A simple automatic hourly rebase would be fine to keep applying .github
onto the top of our fork, not conflicting with anything you are doing.
Completely hands off, unlimited bandwidth releases (with actions seutp).
Sounds cool, do you have any examples of apt/yum/dnf compatible Github releases? I think it's not possible without nested dirs.
Another issue is throttling - for anonymous Github will show "Whoa there! You have triggered an abuse detection mechanism." very fast.
@daiyam wrote:
I will look into it.
That sounds good. Note that If that is done, then we should patch the new file resources/server/bin/helpers/check-requirements-linux.sh.
This new script will definitely help in general.
Sounds cool, do you have any examples of apt/yum/dnf compatible Github releases? I think it's not possible without nested dirs.
Another issue is throttling - for anonymous Github will show "Whoa there! You have triggered an abuse detection mechanism." very fast.
Apologies as I missed this response. Both of those problems are solved simply by publishing Github Pages (which is free, and is hosted at .github.com, such as my blog at https://eduncan911.com). Not really a rate limit issue on static sites. ;)
I am more than happy to work with you and set this app up under your account. The urls for the nested dirs would be something like:
https://paulcarroty.github.com/vscodium-apt/...
https://paulcarroty.github.com/vscodium-yum/...
https://paulcarroty.github.com/vscodium-dnf/...
Each of those being a repo under your account, vscodium-apt, vscodium-yum, and vscodium-dnf. They are publushed as sub-directories.
The only catch there is no large should be hosted on static sites. That's what the Publishing Releases is for, to host the tarball or whatever compressed released file. Then the static files that point to the large tarball to pull and extra... Etc.
@daiyam wrote:
I will look into it.
That sounds good. Note that If that is done, then we should patch the new file resources/server/bin/helpers/check-requirements-linux.sh. This new script will definitely help in general.
Should I just disable the check?
@daiyam as GitMensch mentioned above can we switch to use the custom node to build vscodium so it can support old linux version as vscode does ? I took a look and seems we are using nvm. Unfortunately it does not official support the unofficial build of node, but maybe the below workaround can help. Since I'm not familiar with our build pipeline so I was not able to make the pr I used
18.17.5
just as a random version name, since it need to follow the format to pass the validation phase of nvmwget https://unofficial-builds.nodejs.org/download/release/v18.17.1/node-v18.17.1-linux-x64-glibc-217.tar.xz tar -xf node-v18.17.1-linux-x64-glibc-217.tar.xz mv node-v18.17.1-linux-x64-glibc-217 ~/.nvm/versions/node/v18.17.5 nvm use 18.17.5
Sadly, it's only available for x64. no arm64 or ppc64...
Can you try the version https://github.com/VSCodium/vscodium-insiders/releases/tag/1.86.0.24039-insider? Thx
It's working with libc2.17 (by using reverting to node-16)
Is that a "manual downgrade" or something from upstream?
Would it be useful to use node-v18.17.1-linux-x64-glibc-217 for x64?
It's a manual downgrade... (Linux non-REH were still on node-16 until 1.85) reh-node16.patch
Would it be useful to use node-v18.17.1-linux-x64-glibc-217 for x64?
I did ask myself. I decided to have the same version on the different platforms.
I will see if there is a serious issue and will see at that time.
Sadly, I've just tested in a VM, I'm getting errors from dependencies:
- Error: /lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found
- Error: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.22' not found
I will have to refine more...
@daiyam Vscode released 1.86.1 to support remote legacy server last week microsoft/vscode#204344
Perhaps we can benefit from it ๐
The 1.86.2.24047-insider
does works on centos7 when switching to the unofficial nodejs.
The next version will test node-v16
The latest https://github.com/VSCodium/vscodium-insiders/releases/tag/1.86.2.24048-insider does work on centos7 (only REH)
I'm looking into building node-v18
with glibc-2.17
for platforms other than x64.
VSCodium 1.86.2.24053 should fix the issue.
Thank you - do we include the "pesky not able to be disabled banner" as vscode does? [And if yes, can we provide a disable option as there was for some other message I can't remember?]
I can confirm that the issue is fixed by VSCodium 1.86.2.24053 - thanks!
@GitMensch no I've removed it