Thanks, this worked for me too!
1 Like
I also had to update from the standard Raspbian docker version to the one installed by the get.docker.com convenience script in addition to updating libseccomp2.
1 Like
Software QA seems to be overrated nowadays.
2 Likes
I just changed to Github channel when upgrading to 2021.7 failed, only to test and the problem was the same, In my opinion, Docker Hub images are ok too.
I have a script to update Home Assistant, and with crontab it runs every day. I will try to modify this script in order to check if the HA is ok after the update.
At this moment my script do:
- Download the new image (with docker pull)
- Stop my home assistant container
- Delete my home assistant container (config folder is outside de container, it’s obvious!)
- Launch home assistant with the new image
I think I need to add somethink like:
- test if the home assistant is running ok
if not, do 6 and 7 steps:
6. stop and delete home assissant
7. Launch home assistant with the old image
Into 2021.7: A new entity, trigger IDs and script debugging - Home Assistant explains:
“Our Docker images are now based on Alpine 3.13 and run Python 3.9… Please note, that Alpine 3.13 on ARM devices running a 32-bits operating system (armhf/armv7), requires your Docker version to be at least 19.03.9 (although, we recommend updating to an even higher version). Additionally, you need to have libseccomp 2.42 or newer.”
mystery solved!
5 Likes
Sounds very scary. I don’t think I’m up for that just yet. I have to many installed components, but thanks for the advice.
I just got it to work correctly by updating the libseccomp2 repo with the following commands:
# Get signing keys to verify the new packages, otherwise they will not install
rpi ~$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
# Add the Buster backport repository to apt sources.list
rpi ~$ echo 'deb http://httpredir.debian.org/debian buster-backports main contrib non-free' | sudo tee -a /etc/apt/sources.list.d/debian-backports.list
rpi ~$ sudo apt update
rpi ~$ sudo apt install libseccomp2 -t buster-backports
I got this info from Fix/Workaround - libseccomp2 and Alpine 3.13 - Installing Raspbian Docker 19.04+ on Raspberry Pi 4 Buster (samcater.com)
Only tested it on my rpi4 so far, but it seems to work.
6 Likes
Just adding this in for those with a Rpi3:
I wound up using the alternate route for installing the libseccomp2 library as described by the post from @Nakazen (thanks by the way for finding that). What I did was
wget http://ftp.debian.org/debian/pool/main/libs/libseccomp/libseccomp2_2.5.1-1_armhf.deb
Followed by
sudo dpkg -i libseccomp2_2.5.1-1_armhf.deb
I was having trouble with the commands above when on my Pi. It could be something I was doing, or it could be something about the Pi3.
Additionally, I had to upgrade my docker instance (also as described in the above link from Nakazen. I would follow the instructions on that article as it’s pretty concise and I’m lazy!).
The result is that it worked. I rebooted before testing for good measure.
2 Likes
I tried the suggestions above but they have not worked for me.
Maybe because I am using “docker-compose”?
I’m using docker-compose having the same problem (docker-compose is so wonderful to use though… in general)
Yes and the problem still exists with the latest “stable” docker-compose 2021.7.2
I implemented what @Nakazen explained and it worked for me on my RPI4 self-managed container.
Now, the “funny” fact is that I have an rpi3 with a supervised installation and I didn’t have the issue when upgrading. I always assumed the “container” and “supervised” installation used the same image 
Nevermind. Another workaround is to run the container “privileged”, and the supervised install runs all containers as privileged.
You just saved my day 
Thx for posting the solution 
The problem still exists with the latest “stable” docker-compose 2021.7.3 even with
privileged: true
in my docker-compose.yml file
Should I start a separate thread in this forum?
1 Like
Many thanks to everyone on this thread. Banging my head all morning and into the afternoon trying to figure out what was going on and how to fix. Finally did a search that yielded this thread (previous searches didn’t turn it up till I tried just the right criteria). Thought I was stuck in the mud. Again, THANK YOU all.
Basic question, if anyone cares to answer. I’ve never had to roll back an upgrade. I use portainer. I am obviously missing something because every time I tried to go back to the safety of my 2012.06.x image, Portainer restarted with the 2021.07.x image I pulled today, even after I deleted it. If anyone has a pointer on rolling back, I’d appreciate it. I’m assuming it is easy and I’m just missing it.
Thank you m8, i had the same issue and I solved with those steps
I will try Stefano’s answer which looks like the way to go, although not sure on my pi 3. In the meantime, on my raspberry 3 I got it working by using the seccomp=unconfined option. I assume that disables all the extra security so be aware of that.
See this: Seccomp security profiles for Docker | Docker Documentation
In my docker compose file it was this:
version: '3'
services:
homeassistant:
security_opt:
- seccomp:unconfined
using libseccomp2 buster-backports breaks networking on a docker cluster, causing randomly reboot in containers like traefik, rabbitmq, etc…
More informations here: https://github.com/alpinelinux/docker-alpine/issues/135
Any other way around this ?
1 Like
Thanks all who posted here. I ran into this issue when I updated my instance this morning and was able to fix it by pulling the .deb for the updated library and installing per kwende’s (Ben Rush’s) instructions.
It was a bit of a challenge to figure out which solution to try first. Not all posts referenced the OS in use. I saw the ones that specified buster backports but the first line referenced an Ubuntu server so I didn’t read on but skipped to the next post. In retrospect, I would have preferred configuring backports rather than just downloading the .deb since it would have kept me within the package system a little more.
Anyway… problem solved (at least for now.) There are a number of distros that can run on a Pi (Raspbian 32 and 64, Debian, Arch …) it would be helpful to know which environment a particular fix worked on.
Thanks!
Edit: I too wonder if I should be fetching images from Docker hub or Github.