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

For those running RaspberryPiOs, it looks like a new version of the OS, based on Debian 12, is being released half October, see the last chapter of this article on the official website. Introducing: Raspberry Pi 5! - Raspberry Pi . So, within 2 weeks hopefully.

1 Like

I’m seeing the same issue on Raspberry PiOS Bullseye (based on Debian 11). The only puzzling thing is that it only showed up when I went from 2023.9.3 to 2023.10.0. An attempt to revert to 2023.9.3 failed with the same error (presumably it’s trying to run some of the new code as part of the downgrade process), but when I restored 2023.9.3 from a backup, everything was fine. (For now. I guess I’m stuck on that release until the new version of Raspberry PiOS comes out!)

but when I restored 2023.9.3 from a backup, everything was fine

@psfales can you please elaborate on this? I made the mistake of updating to HA 2023.10.0 and now even though I downgraded back to 9.3 I am getting the libssl error.

Did you have a backup of your whole system from before you upgraded to 10?

I’ve learned that it’s a good idea to back up my HA home directory and my python venv directory periodically. In this case, all had to restore was the venv.

You could probably create a new venv and install 9.3. it would take a little work, but you would keep your HA config and settings.

That seems like a good idea. Will be doing more backups in the future!

Based on a comment above I ended up just downgrading to HA2023.4.0 which was a bit tricky in itself, then found I could upgrade back up to 2023.7.0 without the error returning. I am just going to stay on that version for a couple of weeks until the new Raspberry Pi OS version is out and then will upgrade to the latest HA.

If anybody else is struggling with this, this is what I had to do to get it working on 2023.7.0 again:

pip install "cython<3.0.0" && \
pip install --no-build-isolation pyyaml==6.0 && \
pip install setuptools-rust && \
pip install --no-build-isolation cryptography==40.0.1 && \
pip install homeassistant==2023.4 && \
pip install homeassistant==2023.7.0

I actually also tested setting up a new venv and found that 2023.7.0 was the latest version I could install there that would work as well :confused:

Hello,

Same issue for me.
Is there any solution ?

Regards

This sucks. I’m completly screwed now. I only backed up my configs, but not installation.
After updating to 2023.10 I ran into the same libssl.so.3 issue and I can’t downgrade any longer due to libffi.so.3 missing for 2023.9.3 or 2023.7.3 and a different error on 2023.7.0.
I even tried a fresh raspberry pi os 11 install, not even 2023.7.3 is working. What is happening? The installation instructions for core are safe to say not working anymore.
Any attempt at installing homeassistant, be it 2023.4 up to 2023.9 results in cryptography being unable to be built on a fresh Raspberry Pi OS installation with “libffi.so.8: cannot open shared object file: No such file or directory”
I basically can not install Homeassistant anymore.

Of course there is. Compile openssl 3 from source. This will provide libssl.so.3 and libcrypto.so.3, both needed.

Sure you can. Just complile libffi from source. This will provide libffi.so.8.

I just installed HA 2023.10.0 on my Rpi0 under RPI OS Bullseye yesterday. Works fine. You need to install a few dependencies from source, as the versions in Bullseye are not compatible anymore, but no big deal. The real PITA was that some ARM6 wheels (HA dependencies in Python) use a new GLIBC version, so I had to rebuild them from source too (modules cryptography, bcrypt and orjson mostly, but also pydantic needed to be rebuild from source due to a Cython incompatibility).

Oh and of course you also need to compile Python 3.11 from source first, as this is required from 2023.8.0 onwards iirc.

The only solution that worked for me is to upgrade from bullseye to bookworm my RPI3b+.
Now HA 2023.10.0 is almost running after fresh install on new venv.
But I still have an issue with HACS and radio_browser integration due to pydantic.

File “pydantic/main.py”, line 186, in pydantic.main.ModelMetaclass.new
TypeError: Argument ‘bases’ has incorrect type (expected list, got tuple)

Setup failed for radio_browser: Unable to import component: Exception importing homeassistant.components.radio_browser

pip show pydantic
Name: pydantic
Version: 1.10.12
Summary: Data validation and settings management using python type hints
Home-page: GitHub - pydantic/pydantic: Data validation using Python type hints
Author: Samuel Colvin
Author-email: [email protected]
License: MIT
Location: /xxxxx/lib/python3.11/site-packages
Requires: typing-extensions
Required-by: id, radios, sigstore

2 Likes

Been dumping hours into this but nothing makes it run fully smoothly again. Lesson learnt, automated backup of installation coming right up…

Tried. If only it was that easy. GLIBC needs an update as well and other things do too.
I’m not going down that rabbit hole with my limited knowledge.

Been there done that, I don’t remember the error but it didn’t work either.

Will just have to wait for the Bookworm Raspberry Pi OS release and somehow survive the time without smarthome. :woozy_face:

1 Like

I feel your pain, I also broke my core installation just now when upgrading from 2023.9.3 to 2023.10.0. I’m currently trying out the full upgrade path suggested by @ALaDoffe, and will report back how it goes. If not I will revert back to an older SD card I have from a couple of months back (my database is on another server).

Meanwhile - what automated backup solutions will you go for for a HA core installation on an Rpi? I guess we need some remote place to store the backup in case the SD card breaks down.

Edit: The upgrade did work, however, my Z-wave integration stopped working because of the Pydantic/CPython issue (tracked here) hope it will be sorted out soon. At least, I have my HA dashboard back and working.

1 Like

I just found an old backup of /srv/homeassistant lying around on my system. Maybe I can limp around using this for a while until RPI bookworm is released.

To backup my .homeassistant/ I’m currently using a cronjob that stops HA, does rsync to transfer the files to another RPI (where other backups are rsynced to as well) which then moves it to my windows machine with plenty of storage through a SMB shared drive.
I have a updater script for my HA, I’ll just make it compress /srv/homeassistant and rsync that as well.

1 Like

I have also upgraded to Bookworm and having issues with pydantic. My Google Calendar is not working and Meto-Alarm was not working. I removed both integrations as I have a work-around and now using calDav and importing the Google calendar from our family in my iCloud account. The meteo integration has been replaced with another weather integration.

Also there are some Github issues that i’m following, maybe there will be a solution over there:

1 Like

Of course there is. Compile openssl 3 from source. This will provide libssl.so.3 and libcrypto.so.3, both needed.

Tried that. The compile went OK, upgrading HA resulted in:

    from cryptography.hazmat.bindings._rust import (
ImportError: /lib/arm-linux-gnueabihf/libc.so.6: version `GLIBC_2.33' not found (required by /srv/homeassistant3.11/lib/python3.11/site-packages/cryptography/hazmat/bindings/_rust.abi3.so)

I don’t want to any farther down the path to dependency heck. Hopefully it will work better when the next Raspberry PiOS comes out.

1 Like

It is.

No, you can’t update libc without changing the kernel (and the entire OS), as it is tied to it. But you don’t need to. You just have to build the affected Python packages from source instead of using the precompiled binaries. It will then use the libc that comes with your OS. For example, for cryptography:

pip3 install --no-binary :all: cryptography

Do this with all packages with wheels that use the wrong GLIBC version. It’s a bit annoying, but really not a big deal.

Well, Core is noted as being an advanced install method. You are supposed to handle minor issues like missing or incompatible dependency versions yourself. If you don’t want / can’t do this, then you should possibly think about switching to HAOS.

It may not run out of the box either with Bookworm and these problems above will inevitably come back sooner or later as dependencies go stale. If you use Core, you have to handle this yourself.

Yup, as I mentioned in my post above, you need to build the affected Python packages from source. The provided ‘wheels’ (precompiled binaries) use the wrong libc version.

1 Like

Running

did not resolve the problem. (But it didn’t appear to actually install anything, so maybe there is something more to do)

You need to uninstall the incompatible package (and possibly its dependencies) first, before reinstalling it.

pip3 uninstall cryptography

Just jumping in to say that I also ran into this problem, regretted not taking a backup and have switched to using the docker image instead. It installed quickly on my RPi3B with Raspbian 11 and does everything my venv core install did (once I realised I needed to add -v /run/dbus:/run/dbus:ro to get bluetooth working). I dare say it is even running faster than my previous install, too (totally subjective measurement).

I would encourage those struggling to give it a try. It really was much less painful than I anticipated and I can still use all my custom components and hence do a little development work.

1 Like

The upgrade did work, however, my Z-wave integration stopped working […]

FWIW, for some reason everything went south after I did another restart. Got problems with numpy, openblas (libopenblas.so.0: cannot open shared object file: No such file or directory), Cython, DTLSSocket, urllib (AttributeError: module 'urllib3.util' has no attribute 'PROTOCOL_TLS'), and more, but I got mostly around it by installing a bunch of packages (all might not be needed):

apt install build-essential tk-dev libncurses5-dev libncursesw5-dev libreadline6-dev libdb5.3-dev libgdbm-dev libsqlite3-dev libssl-dev libbz2-dev libexpat1-dev liblzma-dev zlib1g-dev libffi-dev libxml2-dev libxslt-dev libturbojpeg0 rustc python3-opencv libavutil-dev libavformat-dev libavcodec-dev libavdevice-dev libavfilter-dev libswscale-dev libswresample-dev libjpeg-dev libsqlite3-dev libpng-dev zlib1g-dev linux-modules-extra-raspi python3-dev libatlas-base-dev

Then I recreated the python environment, with some specific packaged pinned to old versions:

pip install wheel homeassistant==2023.9.3 mysql==0.0.3 mysqlclient==2.1.1 pymysql python-telegram-bot pillow bellows==0.36.5 mysql-connector-python==8.0.32 beautifulsoup4==4.11.1 urllib3==1.25.11

I still haven’t managed to get my zwave (zwave-js) integration to work, and also got some errors on hacs, stream and default_config. I think they are all related to pydantic, and I currently have pydantic==1.10.12 installed.

Edit: Actually, as suggested by this comment, using pydantic==1.10.10 makes more things working, most importantly the zwave integration :tada:. Still failing for me is stream and default_config, not completely sure what the downsides are yet.

1 Like

default_config fails as a result of stream failing (as stream is part of default_config). Stream is also the only thing I didn’t manage to get working (but then again I didn’t really try, I just removed it from default_config). Numpy was a bit problematic too, but recompiling it fixed it. I also stumbled over the openBlas dependency I had to rebuild, forgot about that one lol.

Oh and what the hell does the mqtt integration need numpy for ?? What a weird dependency.

That said, the newer HA versions are clearly not meant to be installed on such an old OS anymore :grin:

1 Like