Piwheel issues with older versions of Raspbian

If you are using Hass.io, Docker or a distro based on Debian Buster this does not apply to you.

After upgrading to Home Assistant version 0.96.0, some users started seeing errors like this:

ImportError: /usr/lib/arm-linux-gnueabihf/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by /srv/homeassistant/lib/python3.7/site-packages/cryptography/hazmat/bindings/_openssl.abi3.so

And all integrations that communicated with SSL (https) stopped working.

This applies if you have one of these installations with a manual installation or with Hassbian:

  • Raspbian Jessie
  • Raspbian Stretch

The reason for this, is the way piwheels determines the OS version you have by looking at the Python version that is in use.

@frenck added a writeup of the issue and potential solutions to this issue.

There are two potential solutions for this issue, where option 1 are considered the best of them.

Option 1

Upgrade your distribution to Debian Buster.

NB!: This option will upgrade your entire system and might negatively affect other things you might have running.

Before you continue with this, you should make sure that you have a recent backup of your system.


  1. Change stretch or jessie to buster in these files:
    • /etc/apt/sources.list
    • /etc/apt/sources.list.d/raspi.list
    • /etc/apt/sources.list.d/hassbian.list
  2. Run sudo apt-get update
  3. Run sudo apt-get -y dist-upgrade
  4. Run sudo reboot

Option 2

Disable piwheels prebuilt packages.

This option is a faster method initially, but it has the huge drawback of having to compile the packages locally. You should only use this option if you run other things on your system that will not work if you use the first option.


  1. edit /etc/pip.conf and comment out the line containing piwheels, like this:

    # extra-index-url=https://www.piwheels.org/simple
  2. Run source /srv/homeassistant/bin/activate

  3. Run pip uninstall cryptography

  4. Run pip install --no-cache cryptography==2.7

  5. Run deactivate

This is a companion discussion topic for the original entry at https://www.home-assistant.io/blog/2019/07/19/piwheels/

FWIW, I upgraded to Raspbian Buster on a RPi 3B+ cleanly (a clean install of Raspbian) and installed HA again and restored backup of HA configurations. There is a warning against inplace upgrading from Stretch to Buster on raspberrypi.org, which is why I did the clean install.

With this, HA runs smoothly.

There was, however, a problem with building what’s needed for certbot-auto for generating Let’s encrypt certificates (first run of certbot-auto), but that was resolved by renaming /etc/pip.conf for the first run of certbot-auto. That, apparently, is also a piwheels related problem of some sort (way beyond the limits of my skills).

I’ve done the dirty upgrade from Stretch -> Jessie -> Buster over the last few years as per the above method without issue.

I might try the «dirty» upgrade next time around, then. Much less work, it would seem, than the clean install.

This thread ‘issues with older versions of Raspbian’ suggests that Raspbian Stretch is old. Has HA/Hassbian been released for Buster? (Latest I’m finding is 2019-07-02-Hassbian.img)

I tried an inplace upgrade Stretch to Buster per Option 1, and not surprisingly, it failed:
E: Sub-process /usr/bin/dpkg returned an error code (1)
It wouldn’t even reboot.

I went back to my hassbian 4.19.42-v7+ #1219 with 0.95.4.

I don’t think I can entertain Hass.io, as I want to have the same Pi run rtl_433 for receiving wx sensors, Rclone for nightly backups, rpi-clone for complete SSD cloning, and additions to /etc/udev/rules.d to make clones an insert-media-clone-and-dismount experience.

Am I frozen at 0.95.4?
Should I be asking this elsewhere?


Install raspbian stretch and then ha in a venv. You end up with practically the same as hassbian.

I don’t think running HassIO would preclude any of that. HassOS would, but if you install docker on your PI, and install HassIO on that, you could still run all of those other services and tasks on the host, unless there’s something special that I’m missing about what you’re running.

Silicon_Avatar: True, thanks. I didn’t think of that. I would have to learn Docker. I’ll think about that.

nickrout: Install raspbian stretch and then ha in a venv. You end up with practically the same as hassbian.

And that resolve the root cause of this issue that piwheels determines the OS version you have by looking at the Python version? OS or Python will appear different?

Thinking this over. Appreciate the ideas.

Yes, the current release of Hassbian uses Buster.

I’ve upgraded one of my Pi systems from Stretch to Buster without issue, the others are on the “to do” list, but I don’t expect any real problems.

I know many will claim that the distribution upgrade has worked for them but inevitably it may well leave artefacts of the older distribution in place that come back to haunt you at a later date.

Using the Venv method of installation it may well be easier in the long run to back up your HA folders, install Raspbian Buster from scratch and copy over your backed up HA folders into your new Raspbian distribution.

This eliminates any of the Python related issues with older distributions and eliminates the artefacts of previous distributions.

Why introduce the possibility of any system instability into your new distribution when a fresh install will help avoid this.

I started seeing issues with Hass running in venv on raspbian stretch recently and fixed this by upgrading to Buster. It’s worth noting that I reinstalled Hass into a new venv after upgrading to Buster and everything is working perfectly now. I have been using this practice since I started using Hass on raspbian Jessie years ago and have never had an issue.

Just to say thanks for this. This dependency will prevent me from upgrading further than 0.95 for at least 7 to 9 months, and this is not a bad thing - I actually welcome this. Quite some time invested in keeping up with breaking changes over the last 6 months, I really welcome a break :slight_smile:
The key reason for me is that I use the RPi for a lot more than only home assistant, I can’t just upgrade de OS and restart from scratch (even if I had the time :slight_smile: since the other apps are not yet ready for debian buster. Of course, 0.95 has been really stable for me so little incentive to introduce more changes either at this point, even if I could upgrade the OS. Further, there appears to be major breakage in the climate front and I rely on the past behavior heavily. I guess I will use next christmas to re-write my customizations. 10-4 for now.

1 Like

I believe that IS a Buster image, not stretch.

This was absolutely painful to try and upgrade onto a pi with other things running (pi-hole, plex, etc). I ended up separating it onto it’s own Pi 3 B+. It’s probably how it should have been from the start but in the beginning I didn’t know how far down the HA rabbit hole I would get.

I run OSMC/Kodi (as a headless music server) in the same Pi as HA and a few other little things and it all runs fantastically well whenever HA’s “breaking changes” don’t impact my setup. I try hard to minimize the number of boxes I have (little or big) and to optimize the software environment - all at very low power, to save a few trees down the road, and also to minimize hardware waste (I have started to feel guilty every time I throw away electronics and plastics).
From what I could see, the go-forward plan for me will be docker on the pi, it seems to have great support from the community here and it shields you from almost all dependency issues - the container includes all dependencies, python etc so at least no breakage from that side of things. I hear docker has a performance penalty and given my use case I will probably wait until end of the year to migrate to RPi4 with more memory and go docker at that time - giving away the RPi3 to family, it can surely last another 4 years. Hopefully the Pi4 will last a decade.

Thanks for this. I wasn’t sure if it was me that broke something.
The ‘dirty’ fix took ages but worked.

I wouldn’t leave your install too long on that version. The further you drift from the latest version the more effort required playing catch up later.

I really think HA is more suitable to a dedicated RPI setup. It should comfortably run on a Raspberry Pi3+ booting from an SSD fairly trouble free.

I suggest leaving all the other secondary non HA tasks to a separate RPI. Still if you feel you can cram the extra overhead to a solitary RPI stay with your plan.

I was able to move from stretch to buster, but I was using my synology NAS to host a MariaDB database for my recorder, and now I’m getting the following error:
ERROR (Recorder) [homeassistant.components.recorder] Error during connection setup: libmariadbclient.so.18: cannot open shared object file: No such file or directory (retrying in 3 seconds)

I tried running sudo apt-get install libmysqlclient but I receive an error that there is no installation candidate.

I also moved from stretch to buster following option 1 from above and ended up with the same problem (my mariadb database was on my RPi). I finally gave up trying to find a solution and reinstall everything on raspbian buster lite and docker, but you can use the latest hassbian image

Upgrading from Stretch to Buster changed the sql access driver required, I had to move my connection string to:

mysql+pymysql://username:[email protected]_IP_ADDR/homeassistant?charset=utf8