Curl Issues

[lookforhisface]

Good Afternoon,

PVE pve-manager/8.2.7/3e0176e6bb2ade3b (running kernel: 6.8.12-2-pve)

I am running into an issue on two of my PVE's with curl. If I run 'curl --version' i get the following output:
curl: /usr/lib/vmware/libcurl.so.4: no version information available (required by curl)
curl: symbol lookup error: curl: undefined symbol: curl_mime_headers, version CURL_OPENSSL_4

I can't seem to find much information about this on google. I am pretty sure this is preventing me from being able to actually use curl as scripts that utilize curl also fail to run. Any ideas?

 

[BobhWasatch]

Why is there a directory called /usr/lib/vmware in the first place? That's not a normal thing on PVE. Are you running PVE on top of VMware?

ETA: In other words, it looks like you have installed some version of curl on your PVE that did not come from the PVE or Debian repositories.

 

[lookforhisface]

Why is there a directory called /usr/lib/vmware in the first place? That's not a normal thing on PVE. Are you running PVE on top of VMware?

ETA: In other words, it looks like you have installed some version of curl on your PVE that did not come from the PVE or Debian repositories.

The only thing I recall installing was a backup agent via BDR360. I saw the /usr/lib/vmware and it didn't seem correct. What I am unsure how to do is to get the correct version back installed.

 

[LnxBil]

What I am unsure how to do is to get the correct version back installed.

We don't know that either. To us, the system is compromised and need to be reinstalled. Anything that messes with library paths is a total no-go.

 

[BobhWasatch]

To expand on what @LnxBil said, you probably have the Debian version still installed. You can verify with "dpkg -l curl".

The problem is your library path. Curl is a command-line tool + a library. What is happening seems to be that the wrong library version is being found. Which means that whatever you installed either modified the dynamic loader configuration or your system environment variables.

The installer could have edited /etc/ld.so.conf or dropped a config file in /etc/ld.so.conf.d to add /usr/lib/vmware to the library search path. That's the modify-the-loader-configuration way. The other way is to add LD_LIBRARY_PATH to some startup or login script. That's the modify-the-environment way. How you recover depends on which happened.

For the first case you can edit ld.so.conf or delete the added conf file and run "ldconfig" or reboot to recreate the cache. For the second you have to figure out what the installer did.

Maybe it put something in /etc/profile.d or edited /etc/profile or ~/.bashrc or some other startup script? It is just something you have to search for and then undo. Does "echo $LD_LIBRARY_PATH" give any output? If so, the problem is your environment.

And in both cases fixing this might break what you installed.