curl: error while loading shared libraries

[alleyu2]

No didn’t help

root@DietPi-Pi4:~# ldd $(which curl)
        linux-vdso.so.1 (0xbeec6000)
        /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6fa7000)
        libcurl.so.4 => /usr/lib/arm-linux-gnueabihf/libcurl.so.4 (0xb6f11000)
        libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb6ee6000)
        libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb6ebc000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d6e000)
        /lib/ld-linux-armhf.so.3 (0xb6fbc000)
        libnghttp2.so.14 => /usr/lib/arm-linux-gnueabihf/libnghttp2.so.14 (0xb6d3f000)
        libidn2.so.0 => /usr/lib/arm-linux-gnueabihf/libidn2.so.0 (0xb6d13000)
        librtmp.so.1 => /usr/lib/arm-linux-gnueabihf/librtmp.so.1 (0xb6cea000)
        libssh2.so.1 => /usr/lib/arm-linux-gnueabihf/libssh2.so.1 (0xb6cb4000)
        libpsl.so.5 => /usr/lib/arm-linux-gnueabihf/libpsl.so.5 (0xb6c94000)
        libssl.so.1.1 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.1 (0xb6c15000)
        libcrypto.so.1.1 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 (0xb69fb000)
        libgssapi_krb5.so.2 => /usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 (0xb69b1000)
        libkrb5.so.3 => /usr/lib/arm-linux-gnueabihf/libkrb5.so.3 (0xb68f6000)
        libk5crypto.so.3 => /usr/lib/arm-linux-gnueabihf/libk5crypto.so.3 (0xb68b6000)
        libcom_err.so.2 => /lib/arm-linux-gnueabihf/libcom_err.so.2 (0xb68a3000)
        libldap_r-2.4.so.2 => /usr/lib/arm-linux-gnueabihf/libldap_r-2.4.so.2 (0xb684e000)
        liblber-2.4.so.2 => /usr/lib/arm-linux-gnueabihf/liblber-2.4.so.2 (0xb6832000)
        libunistring.so.2 => /usr/lib/arm-linux-gnueabihf/libunistring.so.2 (0xb66b6000)
        libgnutls.so.30 => /usr/lib/arm-linux-gnueabihf/libgnutls.so.30 (0xb6513000)
        libhogweed.so.6 => not found
        libnettle.so.8 => not found
        libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb649a000)
        libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0xb63c0000)
        libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb63ad000)
        libkrb5support.so.0 => /usr/lib/arm-linux-gnueabihf/libkrb5support.so.0 (0xb6393000)
        libkeyutils.so.1 => /lib/arm-linux-gnueabihf/libkeyutils.so.1 (0xb637f000)
        libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb635b000)
        libsasl2.so.2 => /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 (0xb6334000)
        libp11-kit.so.0 => /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 (0xb622f000)
        libtasn1.so.6 => /usr/lib/arm-linux-gnueabihf/libtasn1.so.6 (0xb620f000)
        libnettle.so.6 => /usr/lib/arm-linux-gnueabihf/libnettle.so.6 (0xb61cb000)
        libhogweed.so.4 => /usr/lib/arm-linux-gnueabihf/libhogweed.so.4 (0xb618c000)
        libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0xb6162000)
        libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0xb614a000)
        libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb611d000)

[Joulinar]

maybe you would need to complete the Bullseye upgrade to overcome the situation.

[alleyu2]

I tried that as well but somehow proftpd breaks the upgrade and then it doesn’t continue. I can try again and show you the error. Out of curiosity, this is the out of apt policy for curl.

apt policy curl
curl:
  Installed: 7.64.0-4+deb10u2
  Candidate: 7.64.0-4+deb10u2
  Version table:
     7.74.0-1.3 -1
         -1 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
 *** 7.64.0-4+deb10u2 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
        100 /var/lib/dpkg/status

[Joulinar]

yes if possible pls share the issue with ProFTP but this I would recommend to continue on a new topic for ProFTP issue during upgrade

[MichaIng]

Please run the following:

apt install pax-utils
lddtree /usr/bin/curl

[omavoss]

maybe you would need to complete the Bullseye upgrade to overcome the situation.

Hello,
I apologize in advance, but my problem is not only mine, but that of my whole family.

I have rebuilt Bullseye, installed the Baikal plugin and copied my previously saved directory /var/www/baikal into the new installation, overwriting the original configuration.
Unfortunately Baikal doesn’t work anymore, I get an error message that baikal.yaml can’t connect to mysql.

Baïkal was not able to establish a connexion to the configured MySQL database (as configured in config/baikal.yaml).

I can unfortunately update the old Dietpi system 7.4.2 (beta) because of the curl error nor successfully import the Baikal calendar into the new system 7.6 or Bullseye without losing the existing calendar data. This gives me quite significant problems with my entire family, because the Baikal calendar is synchronized on multiple devices.

Is there any way to get the old baikal.yaml to connect to the new mysql?

Thank you for understanding and kind regards.

Translated with www.DeepL.com/Translator (free version)

[Joulinar]

What about restoring the system to get Baikal back working, even if the curl issue persists

[omavoss]

Hello, there is obviously a misunderstanding here.

I have rebuilt a Dietpi system 7.6.1, there is not the curl problem.There I installed the Baikal plugin and copied the /var/www/baikal directory from Dietpi 7.4.2 (system with the curl problem) into the new Dietpi 7.6.1. Nevertheless the Baikal calendar does not work, it comes the error

Baïkal was not able to establish a connexion to the configured MySQL database (as configured in config/baikal.yaml).


So I would like to repair and update the 7.4.2 system (the one with the curl problem) or run my old baikal.yaml in the new 7.6.1 system (whitout the curl problem).

So this baikal.yaml does work under Dietpi 7.4.2 and not under the new Dietpi 7.6.1.

Thanks for understanding.

[Joulinar]

What is the reason not to update the system running 7.4 to Bullseye?

[omavoss]

Hello,

I follow the howto for upgrading to Bullseye exactly:
https://dietpi.com/blog/?p=811

After the procedure is fully executed and the reboot is due, network connection via eth0 does not work anymore.

Therefore I reset the system with “dietpi-backup -1” and am now back on 7.4.1 with the known curl error.

Thank you.

[Joulinar]

if you have time, and local access, it would be good to check what the issue is. Do you know if something like ifupdown package got removed during Bullseye upgrade?

[omavoss]

Hello, thanks for the tip.
I read and work according to

https://dietpi.com/phpbb/viewtopic.php?t=8954&start=10

and will get back to you. Thank you so far.

[Joulinar]

yes that issue was related to PiHole being removed and there is a dangerous question by the PiHole removal tool. It is asking to remove not needed dependency, which will break your system if you confirm

[omavoss]

Hello,
there is no PiHole installed on the system, it runs Baikal, Yacy, Wireguard and OpenVPN on it.
When I finish the upgrade by “rule”, I go to the local display screen of the system with my notebook and take pictures with my smartphone. This may take a few more minutes . . .

[Joulinar]

Take your time, no need to rush.

[omavoss]

Hello,

the promised pictures in the attachment.

If you want me to enter more or other commands, please let me know.
Thank you very much.

[omavoss]

Two another pictures:

[omavoss]

Another pictures:

[Joulinar]

Interesting no ethernet adapter available. Looks like the kernel module is not loaded correctly.

MichaIng
Any ideas?

[omavoss]

For today, one last picture; if it serves the further development of the update to Bullseye, I can do without the Baikal calendar for a few more days and enter more commands and send pictures of them.