HELP: Suddenly ImportError libssl.so.3: cannot open shared object file

42

A bit off topic, libssl.so.3 is a part I have not seen issues with so far…
setup a new test environment in a Python 3.11 venv today on a spare Raspi 4 8GB, to practice a little bit before updating my production system…
ran into a few issues too like with numpy, rustc ( forgot to customize for “arm-unknown-linux-gnueabihf” while running the install script), but could fix them
HA starts, but now fails to install “webrtc-noise-gain”:

First error seen is:
/usr/lib/gcc/arm-linux-gnueabihf/10/include/arm_neon.h:6898:1: error: inlining failed in call to ‘always_inline’ ‘float32x4_t vmovq_n_f32(float32_t)’: target specific option mismatch

Any known solution for this error?

Armin

43

That error happens when the target architecture g++ is compiling for either doesn’t support ARM Neon intrinsics (accidentally compiling for x86 maybe ?), NEON support is not enabled or the compiler is trying to mix NEON SIMD and standard FP / VFP code in the same function. Usually this points to a problem with the compiler switches supplied to gcc/g++ in the make file. You would fix this by explicitly enabling NEON support using -mfpu=neon in the makefile. See here.

Other option, webrtc-noise-gain is used for this weird open source voice assistance year of the voice thingy they have going on. If you don’t want / use that, just remove all the voice stuff from default_config and this error should go away.

44

Thanks
I guess I created perhaps a bit of a mess myself by using an existing SD-Card with 32bit Bullseye-image on the Pi4 with 8GB. Downloaded webrtc-noise-gain and built from source, changed setup.py so that for aarch64 it uses options like for armv7… good enough for me for some testing… HA does not complain anymore during startup

I’m not using default_config and “assist” is not in my configuration, but obviously “mobile_app” also forces this dependency

Thanks for the help, I won’t mark the answer as solutiuon, as this would confuse people looking for a solution for the libssl.so.3 problems

Armin

45

Even though I created a backup of my Home Assistant core installation before the update to 2023.10.1 I did a downgrade to 2023.8.4 to solve the issue with libssl.so.3 on Debian 11.

sudo -u homeassistant -H -s
source /opt/homeassistant/bin/activate
pip3 install homeassistant==2023.8.4

This is not the first time in the past months that a new HA release has dependencies that can’t be met with my current installation. I remember another mess with ffmpeg version. I love HA but lately it starts to get annoying that after every other update there is an issue which can’t be easily fixed and requires a lot of time to resolve.

1 Like
46

I feel the same.

I think it would be good if there was just a bit more information to the Core users in the release notes. In fact, due to all the small problems related to Core over the years and the common responses that “one should be capable of this and that” and that we more or less use Core just to be trouble, and now this problem with 2023.10.0 that was not easily solved for me I threw it all out this weekend and installed HAOS and spent a day to migrate over things. It includes a second rpi to run some stuff that isn’t supported by HOAS (one of the reasons I chose Core in the first place).

Luckily for me, at this point in time, most of the hardware that kept me at Core is outdated (eg Telldus Duo USB dongle), so I was able to do the leap.

At least now I am a bit closer to the officially recommended platform. I’m not 100% happy, since the SSH capabilities are not that good in my opinion (lack of persistent storage of eg. .bashrc, ssh keys etc, and I needed to remove most of my command_line integrations, etc.) but it works. And I hope I will be able to roll back to a backup in case I mess up an installation again. Yes, I do take regular backups to an remote storage.

1 Like
47

Raspberry Pi Os based on bookworm (debian 12) has been release today. Haven’t tried it yet to see if it solves the issue.

https://www.raspberrypi.com/software/operating-systems/

48

I’ve spent about 6 hours so far, trying to get everything installed and working on the new bookworm image. numpy was the trickiest, but there were a bunch of other dependencies and interactions that I had to work through. (Some of those were related to the custom hardware I have connected directly to the Pi - that has to be ported over to the new Pi and would make it even more difficult to switch to some other platform. )

But it’s look promising. I have HA 2023.10.1 running on a test machine running Bookworm with (nearly?) all the integrations installed and working. Next step is to try and move that over to the real machine!

49

Well it took a lot of work to get there, and it’s not for the faint of heart. But I’ve got 2023.10.2 loaded on a Pi 3B+ running Bookworm and everything seems to be pretty much OK.

The transition from Buster to Bullseye was much smoother, this one (Bullseye to Bookworm) had a lot more rough edges, dependencies, interactions, configuration changes, etc. Hopefully it won’t be necessary to go through that process again any time soon.

50

I am a bit disappointed that ran into the issue so easily on my live environment :roll_eyes:.

After night of unsuccessful compiling openssl3 (there was something wrong with --merch parameter), gave up.

Finally, upgrade to Bookworm helped. I used the following Upgrade Raspberry Pi OS from Bullseye to Bookworm, went well.

After OS upgrade, HA 2023.10.2 (as well as 8.2, 9.3) failed with MQTT (and Tasmota), Generic camera, and mobile app.

The below, up to “pip install ./pydantic-1.10.12” (because python -c didn’t go), helped.
[quote=“mgee, post:40, topic:612319”]
Edit: Actually, as suggested by this comment , using pydantic
[/quote]

Now looks only the generic camera integration does not work despite it is loaded without errors which was not the case before installing pydantic.

//edit regarding to the above: MQTT (and mobile app) fails on 2023.10.x so needed to revert to 2023.9.3.
To sum up: after OS upgrade from Bullseye to Bookworm (needed because of subject issue), 2023.9.3 is stable. 2023.10.3 starts up, but the integrations as the above fail.

Thanks for advices!

Are there any best practices to clean up OS after the OS upgrade (I mean anything more than apt autoremove etc.)?

51

I also encountered this error when upgrading my home assistant core running in a venv environment to version 2023.10.3. My platform is rpi4 with raspbian bullseye.
I had no backup of the venv and after reading through this thread and trying to downgrade (which failed) I decided to switch to docker. I already had some related components (e.g. zwavejs2mqtt) running in docker so it was not a big deal. The only problems I had were with usb device mappings, and I had to direct the raw devices (/dev/serial/by-id/…) to simple /dev/ttyUSB0, USB1 … since apparently the /dev/serial -subdirectory is not present on the docker image. I also had to configure mariadb to listen on all interfaces (instead of just localhost) and change the address in my configuration.yaml from localhost to the real ip address of my server. The docker based installation feels faster than the old venv based install.

Here’s my docker-compose section, which worked (almost) seamlessly with the home assistant configuration I had running in the venv.

  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/home-assistant:stable"
    volumes:
      - /home/homeassistant/.homeassistant:/config
      - /etc/localtime:/etc/localtime:ro
    devices:
      - '/dev/serial/by-id/usb-RFXCOM_RFXtrx433_A1YI1ZX6-if00-port0:/dev/ttyUSB1' 
      - '/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0:/dev/ttyUSB0'
    restart: unless-stopped
    privileged: true
    network_mode: host
1 Like
52

I’m pretty sure it is not the right way of doing it but somehow I decided to upgrade home assistant on a saturday night thinking to be ready to roll in 10 minutes, and here I am after 1 hour. So here is what I did.

After upgrading from 2023.9.1 to 2023.10.4 I realized it was failing because of cryptography and libc.so. Downgrading again homeassistant didn’t help.

Compiled OpenSSL from source following some steps of this guide How to Update OpenSSL on Raspberry Pi, I only had to add linux-armv4 to avoid issues because of the 64 bit architecture.
Then it started to complain because of GLIB so I uninstalled cryptography and installed it again without binary.

After that I restarted again home assistant and it worked.
I suspect now it will work also with 2023.10, however given how long it took me to fix this I’ll probably take some time and do a fresh install of the new debian release when I have some time.

1 Like
53

Could you perhaps elaborate a bit on how you got webrtc-noise-gain to compile?

With the -mfpu=neon flag, I still run into the following issues:

gcc -pthread -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fno-semantic-interposition -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -ljemalloc -DTHREAD_STACK_SIZE=0x100000 -mfpu=neon-fp-armv8 -fPIC -DVERSION_INFO=1.2.3 -I/tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing -I/tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1 -I/tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/subprojects/abseil-cpp-20230125.1 -I/tmp/pip-build-env-lrvh_9wi/overlay/lib/python3.11/site-packages/pybind11/include -I/srv/homeassistant/include -I/usr/local/include/python3.11 -c /tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1/common_audio/signal_processing/cross_correlation_neon.c -o build/temp.linux-aarch64-cpython-311/tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1/common_audio/signal_processing/cross_correlation_neon.o -fvisibility=hidden -g0 -DWEBRTC_LIBRARY_IMPL -DWEBRTC_ENABLE_SYMBOL_EXPORT -DNDEBUG -DWEBRTC_APM_DEBUG_DUMP=0 -D_GNU_SOURCE -DWEBRTC_LINUX -DWEBRTC_THREAD_RR -DWEBRTC_POSIX -DWEBRTC_ARCH_LITTLE_ENDIAN -DWEBRTC_ARCH_ARM64 -DWEBRTC_ARCH_ARM_FAMILY -DWEBRTC_ARCH_64_BITS -DWEBRTC_HAS_NEON
  /tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1/common_audio/signal_processing/cross_correlation_neon.c: In function ‘DotProductWithScaleNeon’:
  /tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1/common_audio/signal_processing/cross_correlation_neon.c:33:22: warning: implicit declaration of function ‘vmull_high_s16’; did you mean ‘vmull_high_p64’? [-Wimplicit-function-declaration]
     33 |     int32x4_t tmp1 = vmull_high_s16(seq1_16x8, seq2_16x8);
        |                      ^~~~~~~~~~~~~~
        |                      vmull_high_p64
  /tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1/common_audio/signal_processing/cross_correlation_neon.c:33:22: error: incompatible types when initializing type ‘int32x4_t’ using type ‘int’
  /tmp/pip-install-1ehdnnwe/webrtc-noise-gain_0fc7611a1747465e98ac19ac87839ded/webrtc-audio-processing/webrtc-audio-processing-1/common_audio/signal_processing/cross_correlation_neon.c:56:18: warning: implicit declaration of function ‘vaddvq_s64’; did you mean ‘vaddq_s64’? [-Wimplicit-function-declaration]
     56 |   int64_t sum2 = vaddvq_s64(sum0);
        |                  ^~~~~~~~~~
        |                  vaddq_s64
  Traceback (most recent call last):
    File "/tmp/pip-build-env-lrvh_9wi/overlay/lib/python3.11/site-packages/setuptools/_distutils/unixccompiler.py", line 185, in _compile
      self.spawn(compiler_so + cc_args + [src, '-o', obj] + extra_postargs)
    File "/tmp/pip-build-env-lrvh_9wi/overlay/lib/python3.11/site-packages/setuptools/_distutils/ccompiler.py", line 1041, in spawn
      spawn(cmd, dry_run=self.dry_run, **kwargs)
    File "/tmp/pip-build-env-lrvh_9wi/overlay/lib/python3.11/site-packages/setuptools/_distutils/spawn.py", line 70, in spawn
      raise DistutilsExecError(
  setuptools._distutils.errors.DistutilsExecError: command '/usr/bin/gcc' failed with exit code 1

I get the feeling that I miss another compiler flag.

54

I altered setup.py if I recall correctly.
removed aarch64 from this line
if machine in ("aarch64", "armv8", "arm64"):
and added aarch64 to this line
elif machine in ("armv7", "armv7l"):
besides -mfpu=neon this also adds -DWEBRTC_HAS_NEON

I’m not sure if this is the correctly way to handle this, but it worked for me on my test system

On my Live system I did a full upgrade to bookworm, no such issues there.

Armin

1 Like