Entware "Wrong ELF class" or "Error while loading shared libraries" error

[ryzhov_al]

Entware uses lightweight opkg package manager, which is too primitive to track down dependencies change.

Let say, some program depends on `libssl.so.1.0` file but it was replaced by `libssl.so.1.1` while running `opkg upgrade`.
So, you program will fail to start next time because of `libssl.so.1.0` absence.

The solution is to re-install program, which brings you the same version of program, but right relations between dependent files.


Entware site always keeps consistent relations between packages, but local deployment may not)

 

[archiel]

Entware uses lightweight opkg package manager, which is too primitive to track down dependencies change.

Let say, some program depends on `libssl.so.1.0` file but it was replaced by `libssl.so.1.1` while running `opkg upgrade`.
So, you program will fail to start next time because of `libssl.so.1.0` absence.

The solution is to re-install program, which brings you the same version of program, but right relations between dependent files.


Entware site always keeps consistent relations between packages, but local deployment may not)

I don't know what others have done and whether they have the same experience, but I removed the package in its entirety, rebooted and re-installed. The error persists and a re-install does NOT help. Until Scribe is modified it does not look as if it will work with libopenssl 3.0.8.

 

[Ripshod]

The error persists and a re-install does NOT help. Until Scribe is modified it does not look as if it will work with libopenssl 3.0.8.

Not strictly true. All my add-ons are working fine after a factory reset and rebuild - including scribe. Entware is reporting libopenssl 3.0.8-2.

 

[archiel]

As noted in the other thread, on my setup scribe is now working however the error message

Router syslog-ng[29218]: Error opening plugin module; module='http', error='libssl.so.1.1: wrong ELF class: ELFCLASS32'

persists. Is shows in syslog-ng.log every hour during the configuration reload.

Are you saying that this message is not showing on your setup?

 

[Ripshod]

Are you saying that this message is not showing on your setup?

I am.

Mar 16 17:34:10 ripshod syslog-ng[9931]: syslog-ng starting up; version='3.38.1'
Mar 16 17:34:12 ripshod syslog-ng[9931]: Configuration reload request received, reloading configuration;
Mar 16 17:34:12 ripshod syslog-ng[9931]: Configuration reload finished;
Mar 16 18:46:27 ripshod syslog-ng[9931]: syslog-ng shutting down; version='3.38.1'

It's not reloading hourly (?)

 

[BOFH]

Entware uses lightweight opkg package manager, which is too primitive to track down dependencies change.

Let say, some program depends on `libssl.so.1.0` file but it was replaced by `libssl.so.1.1` while running `opkg upgrade`.
So, you program will fail to start next time because of `libssl.so.1.0` absence.

The solution is to re-install program, which brings you the same version of program, but right relations between dependent files.


Entware site always keeps consistent relations between packages, but local deployment may not)

Hi ryzhov_al,

I re-installed curl as you recommended but the problem still occur:

curl: error while loading shared libraries: libssl.so.1.1: wrong ELF class: ELFCLASS32

Edit:

After reinstalling libcurl, issue is fixed.

 

[ryzhov_al]

Also, `opkg depends` doesn't reveal whole dependency tree:

~ # opkg depends curl | grep -v 'depends on'
    libc
    libssp
    librt
    libpthread
    libcurl

Here's the simple way to show three layers depth sub-deps:

~ # opkg depends curl | xargs opkg depends | xargs opkg depends| sort -u
    ca-bundle
    libatomic
    libc
    libcurl
    libgcc
    libopenssl
    libpthread
    librt
    libssp
    zlib
…

 

[glehel]

For me, this is the solution for the scribe AX88u.


opkg --force-depends remove libcurl
opkg install libcurl

And reinstall scribe

 

[kman]

I'm facing similar issue with Transmission.

I used --force-reinstall to reinstall libcurl

opkg install --force-reinstall libcurl

This was able to get Transmission started, however, shortly after I noticed if encryption is enabled in the settings.json, it crashes with OpenSSL error.

Mar 17 01:07:02 kernel: potentially unexpected fatal signal 11.
Mar 17 01:07:02 kernel: CPU: 2 PID: 13003 Comm: transmission-da Tainted: P           O    4.1.52 #2
Mar 17 01:07:02 kernel: Hardware name: Broadcom-v8A (DT)
Mar 17 01:07:03 transmission-daemon[13001]: tr_crypto_utils OpenSSL error: error:0308010C:digital envelope routines::unsupported (crypto-utils-openssl.c:189)

Does this mean Transmission needs to be updated or is there a workaround of reinstalling?

 

[glehel]

I'm facing similar issue with Transmission.

I used --force-reinstall to reinstall libcurl

opkg install --force-reinstall libcurl

This was able to get Transmission started, however, shortly after I noticed if encryption is enabled in the settings.json, it crashes with OpenSSL error.

Mar 17 01:07:02 kernel: potentially unexpected fatal signal 11.
Mar 17 01:07:02 kernel: CPU: 2 PID: 13003 Comm: transmission-da Tainted: P           O    4.1.52 #2
Mar 17 01:07:02 kernel: Hardware name: Broadcom-v8A (DT)
Mar 17 01:07:03 transmission-daemon[13001]: tr_crypto_utils OpenSSL error: error:0308010C:digital envelope routines::unsupported (crypto-utils-openssl.c:189)

Does this mean Transmission needs to be updated or is there a workaround of reinstalling?

yes, I think the transmission needs to be reinstalled

 

[kman]

yes, I think the transmission needs to be reinstalled

Same issue, tr_crypto_utils OpenSSL error: error:0308010C:digital envelope routines::unsupported (crypto-utils-openssl.c:189).

I tried the following:

opkg remove --autoremove transmission-web
opkg --force-depends remove libcurl
opkg install libcurl
opkg install transmission-web

I believe the Transmission binaries need to be updated to work with the latest libopenssl. For now, I've set encryption to 0.

 

[Ripshod]

There's a lot more to transmission than just transmission-web. From memory there's also transmission-daemon and transmission-remote. I would think transmission-daemon would be essential.

 

[kman]

I tried again even removed libopenssl and reinstalled transmission-daemon and it's the same result. digital envelope routines::unsupported (crypto-utils-openssl.c:189)

I think the current Transmission version (3.00-19) isn't compatible with the latest libopenssl. There are suggestions of passing --openssl-legacy-provider but not sure if that's possible using entware.

@ryzhov_al any idea about this?

EDIT: tagged ryzhov_al

 

[StarkWiz]

I have posted a possible solution for this issue in a different thread.
Link to Fix

 

[kman]

I have posted a possible solution for this issue in a different thread.
Link to Fix

Thanks will check it out. With that solution I’m just worried about it cooking up something else. In the interim, force reinstall libcurl at least gets transmission working, it’s just the encryption bit that errors out.

I tried the new libopenssl 3.0.8-2a and still same result.

 

[spykos]

For me the fix was to format my ENTWARE usb flash and install everything from scratch.

 

[kman]

I’m really trying to avoid that. Reconfiguring diversion, skynet, etc. hoping there’ll be an update to transmission sooner rather than later.

 

[kman]

For me the fix was to format my ENTWARE usb flash and install everything from scratch.

Did transmission work for you after formatting? If so, did you have encryption:1 in the settings.json?

As soon as I load a torrent file the daemon crashes when encryption enabled.

 

[spykos]

Did transmission work for you after formatting? If so, did you have encryption:1 in the settings.json?

As soon as I load a torrent file the daemon crashes when encryption enable

Yes it works but I am not using encryption. I can try it with encryption on if you want.

 

[kman]

Yes it works but I am not using encryption. I can try it with encryption on if you want.

Yes, please if you don’t mind. Curious if that works. Encryption : 1