i just updated to libseccomp2_2.4.4-1~bpo10+1_armhf.deb and it works for me
And if the package is not available? E.g. for CentOS7 ARM?
Woke up this morning and found all my HASS deployments down.
Not too sure what happened, but would like to prevent it in the future. Any ideas?
Very noob move, but I just copied the “wget” command as is under option 1 without check if it’s the latest version as explained the block just below. It did work though.
After rebooting my PI, my HASS container restarted without any issues.
Not sure if this is the best solution, but would like to prevent a fatal crash after an automatic update to happen again.
The age old question stands - do I allow automatic updates? - Dammed if I do, Dammed if I don’t.
Thank you for posting this solution. I already thought that my disk was corrupted because the error message was so unspecific. I hope that installing the newer library won’t have any side effects regarding the rest of the system running outside of docker.
If I remeber correctly, home assistant already planned to drop support for custom docker setups, which is a bummer. I hope bugs like this won’t happen more often in the future.
I use a raspberry pi 4, and ghcr.io/home-assistant/raspberrypi4-homeassistant:stable image.
You mentioned that you are getting the docker images from Github now. Is that the new official channel? Up until a few days ago I fetched the docker images from Docker Hub.
Thanks,
on a Raspberry PI4 after upgraded libseccomp2 using the following step
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list
sudo apt update
sudo apt install -t buster-backports libseccomp2
everithing seems fine.
Thanks, this worked for me too!
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.
Software QA seems to be overrated nowadays.
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!
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.
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.
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.