VS Code 1.66 requires GLIBC 2.25 on RHEL 7

[bddali]

VS Code version: code-1.66.0-1648620680
OS: Red Hat Enterprise Linux 7.9

Running yum update on RHEL 7 produces an error:

Error: Package: code-1.66.0-1648620680.el7.x86_64 (code)
Requires: libc.so.6(GLIBC_2.25)(64bit)

According to https://code.visualstudio.com/docs/supporting/requirements the required version of GLIBC is 2.15 or later.

Red Hat Enterprise Linux 7 uses GLIBC 2.17.

[dirtyharrycallahan]

Just ran into this when trying to upgrade this moring.

[cmille62]

I also ran into this problem trying to install today

$ sudo yum install code
Loaded plugins: langpacks, versionlock
Resolving Dependencies
--> Running transaction check
---> Package code.x86_64 0:1.66.0-1648620680.el7 will be installed
--> Processing Dependency: libc.so.6(GLIBC_2.25)(64bit) for package: code-1.66.0-1648620680.el7.x86_64
--> Finished Dependency Resolution
Error: Package: code-1.66.0-1648620680.el7.x86_64 (code)
Requires: libc.so.6(GLIBC_2.25)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

[bpasero]

cc @deepak1556 @rzhao271

[markusdd]

can confirm as well.

There finally needs to be a pipeline that checks RHEL/CentOS 7 comptability. This is a very important stable developer OS with support until 2024.

We went through this with the false electron update a while back and now this silently broke again.

[kevinbwusa]

Same problem here:
yum update -y code  50.54 Dur  18:39:25
Loaded plugins: enabled_repos_upload, langpacks, package_upload, product-id, search-disabled-repos, subscription-manager
rhel-7-server-extras-rpms | 2.0 kB 00:00:00
rhel-7-server-optional-rpms | 2.0 kB 00:00:00
rhel-7-server-rpms | 2.0 kB 00:00:00
rhel-7-server-satellite-tools-6.7-rpms | 2.1 kB 00:00:00
rhel-server-rhscl-7-rpms | 2.0 kB 00:00:00
Resolving Dependencies
--> Running transaction check
---> Package code.x86_64 0:1.65.2-1646927812.el7 will be updated
---> Package code.x86_64 0:1.66.0-1648620680.el7 will be an update
--> Processing Dependency: libc.so.6(GLIBC_2.25)(64bit) for package: code-1.66.0-1648620680.el7.x86_64
--> Finished Dependency Resolution
Error: Package: code-1.66.0-1648620680.el7.x86_64 (code)
Requires: libc.so.6(GLIBC_2.25)(64bit)

---

Dependency resolving failed due to missing dependencies.
Some repositories on your system are disabled, but yum can enable them
and search for missing dependencies. This will require downloading
metadata for disabled repositories and may take some time and traffic.

---

rhel-7-server-supplementary-rpms/x86_64 | 2.0 kB 00:00:00
rhel-7-server-ansible-2-rpms/x86_64 | 2.4 kB 00:00:00
rhel-7-server-satellite-tools-6.6-rpms/x86_64 | 2.1 kB 00:00:00
rhel-7-server-rh-common-rpms/x86_64 | 2.1 kB 00:00:00
--> Running transaction check
---> Package code.x86_64 0:1.66.0-1648620680.el7 will be an update
--> Processing Dependency: libc.so.6(GLIBC_2.25)(64bit) for package: code-1.66.0-1648620680.el7.x86_64
--> Finished Dependency Resolution
Error: Package: code-1.66.0-1648620680.el7.x86_64 (code)
Requires: libc.so.6(GLIBC_2.25)(64bit)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
Uploading Enabled Repositories Report
Loaded plugins: langpacks, product-id, subscription-manager
Time: 0h:00m:11s

[chriscasola]

It it possible this issue would also cause the vscode remote server to fail to start inside a rhel 7 container? I can no longer use the "clone in container" option with a project using a rhel7 base image.

Here is the log output from the dev container:

[13004 ms] Start: Run in container: docker ps -q -a --filter [email protected]:FactSet/cpp-stach.git --filter label=vsch.local.repository.volume=cpp-stach-60afff3647d104e45b988ec63551a168 --filter label=vsch.local.repository.folder=cpp-stach --filter label=vsch.quality=stable
[15158 ms] Start: Run in container: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js up --container-data-folder .vscode-server/data/Machine --container-system-data-folder /var/vscode-server --workspace-folder /workspaces/cpp-stach --workspace-mount-consistency cached --id-label [email protected]:FactSet/cpp-stach.git --id-label vsch.local.repository.volume=cpp-stach-60afff3647d104e45b988ec63551a168 --id-label vsch.local.repository.folder=cpp-stach --id-label vsch.quality=stable --log-level debug --config /workspaces/cpp-stach/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-5f85aed4-ed88-4858-97bf-6e79189154d3.json --mount type=volume,source=cpp-stach-60afff3647d104e45b988ec63551a168,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root true --terminal-columns 158 --terminal-rows 38
[17143 ms] remote-containers 0.231.1.
[17142 ms] Start: Resolving Remote
[17181 ms] Start: Run: git rev-parse --show-cdup
[17250 ms] Start: Run: docker ps -q -a --filter [email protected]:FactSet/cpp-stach.git --filter label=vsch.local.repository.volume=cpp-stach-60afff3647d104e45b988ec63551a168 --filter label=vsch.local.repository.folder=cpp-stach --filter label=vsch.quality=stable
[17656 ms] Error: Command failed: docker ps -q -a --filter [email protected]:FactSet/cpp-stach.git --filter label=vsch.local.repository.volume=cpp-stach-60afff3647d104e45b988ec63551a168 --filter label=vsch.local.repository.folder=cpp-stach --filter label=vsch.quality=stable
[17656 ms]     at ER (/root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js:218:986)
[17656 ms]     at qw (/root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js:218:924)
[17656 ms]     at processTicksAndRejections (internal/process/task_queues.js:95:5)
[17656 ms]     at async RR (/root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js:223:2024)
[17657 ms]     at async Jw (/root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js:223:3221)
[17657 ms]     at async TR (/root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js:223:13880)
[17657 ms]     at async FR (/root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js:223:13605)
[17685 ms] Exit code 1
[17685 ms] Start: Run: docker rm -f b9f33953b979a0fcd8271e963bd43e0da3f9068ed5efbbed1c6e179c7c00df29
[17687 ms] Command failed: node /root/.vscode-remote-containers/dist/dev-containers-cli-0.231.1/dist/spec-node/devContainersSpecCLI.js up --container-data-folder .vscode-server/data/Machine --container-system-data-folder /var/vscode-server --workspace-folder /workspaces/cpp-stach --workspace-mount-consistency cached --id-label [email protected]:FactSet/cpp-stach.git --id-label vsch.local.repository.volume=cpp-stach-60afff3647d104e45b988ec63551a168 --id-label vsch.local.repository.folder=cpp-stach --id-label vsch.quality=stable --log-level debug --config /workspaces/cpp-stach/.devcontainer/devcontainer.json --override-config /tmp/devcontainer-5f85aed4-ed88-4858-97bf-6e79189154d3.json --mount type=volume,source=cpp-stach-60afff3647d104e45b988ec63551a168,target=/workspaces,external=true --mount type=volume,source=vscode,target=/vscode,external=true --skip-post-create --update-remote-user-uid-default off --mount-workspace-git-root true --terminal-columns 158 --terminal-rows 38
[17688 ms] Exit code 1
[17917 ms] Container server terminated (code: 137, signal: null).

[deepak1556]

@chriscasola it is unrelated, please open a separate issue for it at https://github.com/microsoft/vscode-remote-release/issues to investigate further, thanks!

[deepak1556]

Just an update on the issue, it is not caused by electron update. Rather with 1.66 we automated the process of how the package dependencies are generated as part of our build pipeline #17142, which now generates the right set of dependencies for all the native modules and binaries shipped with the package. The current GLIBC_2.25 requirement was generated from one our native module dependency and this modules dependency has not changed for a while now, basically we were previously shipping with an incorrect dependency list which was now caught.

Although we had a test plan item for verifying this new process #145608, we had missed to verify on CentOS 7. Sorry about the update breakage!

[markusdd]

thank you for the update! Is there an ETA for a fix?

This is currently causing a lot of stir because regular updates now fail without the --skip-broken option.

[deepak1556]

Verification steps on CentOS 7:

• Download latest rpm from https://code.visualstudio.com/insiders/#linux
• rpm -ivh <rpm-file>
• Launch the application and login to settings sync
• Ensure the credentials are encrypted in the system keystore for key starting with vscode-insiders-

[cmille62]

This still does not allow installation:

rpm -ivh code-insiders-1.67.0-1649050674.el7.x86_64.rpm error: Failed dependencies: libc.so.6(GLIBC_2.25)(64bit) is needed by code-insiders-1.67.0-1649050674.el7.x86_64

sudo yum install code Loaded plugins: langpacks, versionlock Resolving Dependencies --> Running transaction check ---> Package code.x86_64 0:1.66.0-1648620680.el7 will be installed --> Processing Dependency: libc.so.6(GLIBC_2.25)(64bit) for package: code-1.66.0-1648620680.el7.x86_64 --> Finished Dependency Resolution Error: Package: code-1.66.0-1648620680.el7.x86_64 (code) Requires: libc.so.6(GLIBC_2.25)(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

[markusdd]

yep, still incorrect

[deepak1556]

Insiders with the fix has not been released yet, it will be notified in this thread once the builds are available.

[imokech]

I have the same problem and I could not install VSCode 1.66 on centos 7.

[ajkerzner]

Looks good to me, RHEL 7.9 with the insider build via standard install.
Workaround: rpm -Uvh --nodeps <vscode rpm>.

[bddali]

Succesfully installed code-insiders-1.67.0-1649156474.el7.x86_64.rpm on RHEL 7.

/verified

[selwynchambersmetoffice]

@deepak1556 so is this issue fixed?

[paulds1]

I'm not familiar with vscode release procedures... What is the timeline for getting the fixed build pushed to Stable? Just wondering when we should expect our production systems to see the update.

[isidorn]

To learn more about our recovery releases please read this wiki post https://github.com/microsoft/vscode/wiki/Running-the-Endgame#recovery-build
To understand our development process better please check this out https://github.com/microsoft/vscode/wiki/Development-Process

This fix should be in stable either tomorrow, or early next week. So in the next 6 days.
In the meantime please use the vscode insiders build if you are blocked, it has the fix. Thanks