It’s obvious to unhold it, it’s not obvious if the (new or existing?) version of cli has stopped creating problems.
On my side the new docker-version has stopped creating problems. All is back to normal. Now running:
docker-ce | 5:20.10.5~3-0~debian-buster
docker-ce-cli | 5:20.10.5~3-0~debian-buster
containerd.io | 1.4.3-1
To get there is fairly trivial. Open the CLI, unhold above packages (if you have set them on hold after after going back to <= docker 5:20.10.3) by running:
sudo apt-mark unhold docker-ce docker-ce-cli containerd.io
and thereafter:
sudo apt update && apt upgrade -y && apt autoremove
and you should be good.
HA is running on Docker 20.10.5 without any hiccups here.
2 Likes
Ok, thanks a lot, I’ll give it a try now. Hope it holds after reboot.
Confirm, that fixed in new docker version.
Out of curiosity, where exactly can I see the latest version of docker-ce, the changelogs etc.? Here https://github.com/docker/docker-ce/releases and here https://docs.docker.com/engine/release-notes/ seem to follow a different versioning and I can’t locate something better for our HA installations.
Edit: I think I found it here https://github.com/docker/cli/releases but with no changelogs etc.
The latest havnt be published yet, but you can see commit for 20.10.5 here
docker.github.io/index.md at master · docker/docker.github.io
Client
- Revert docker/cli#2960 to fix hanging in
docker start --attachand remove spurious “Unsupported signal: . Discarding.” messages docker/cli#2987
Hmm,
I got a problem after I want to upgrade to supervisor version 2021.03.3:
[supervisor.core] Update '2021.02.11' of Supervisor '2021.03.3' failed!
Apt-get would disagree. The tag for it was published yesterday.
I use a script (a bash shell one) as well as a few HA sensors but the bash script seems most up-to-date.
Any other information? 2021.03.3 is working for me here…
I was referring to the release notes
I can confirm, upgrading to Docker 20.10.5 has resolved my issues. Thanks!
I have reinstalled home assistant and now it is working. I think something else went wrong in the first place.
1 Like
Although I love this site, its search sucks, so sorry if this was asked before, I can’t find it.
On Rasbian, it’s easy to turn off the Pi’s LED. Those commands do not work in Debian so the question is, how to I turn off the red and green light on a Raspberry Pie 3B running Debian 10?
Thanks
I installed Home Assistant Supervised on Debian 10 on a Raspberry Pi 4. All working properly so far. However, what I’m missing is being able to address the GPIO ports.
With HASSIO this worked previously. So the hardware ports are ok.
Are there any suggestions on how to achieve this with Debian 10?
My previous crappy SSD failed after just three months, and now I’ve put some effort into reducing disk writes to try and extend the life of the new one.
I put it on paper, should anyone be interested…
Sorry if this the wrong thread to post this, but I think the answer to this question may be related to how I have installed HA (supervised on Debian Buster/64 on pi):
What is the currently recommended method for a complete backup of the complete pi installation, not just HA supervised through snapshots (I mean the whole system-bootable or .img)? I boot from an SSD connected to a USB3 port. Ideally I would like to automate such a procedure at a given time point. Target could be an SD, USB stick/HDD or network. I’ve run across https://github.com/billw2/rpi-clone and https://github.com/framps/raspiBackup along with various other tutorials/methods. But they usually talk about SD backups etc. and it seems that the whole procedure could be a tad easier (GUI oriented). Why can’t more “mainstream” solutions be used, like for example https://www.bacula.org/ ?
Finally, I see in all tutorials that it’s recommended to stop various services before the actual backup process is started. Which services should be stopped in HA supervised installation before a complete backup?
You’re always going to have to stop a boatload of services to make a reliable backup on a running system.
The only recommended way to backup an entire system drive is :
*shut down system
*clone the OS drive, using something like Clonezilla.
However, if your Pi is only running Home Assistant, then there’s really no valid reason to avoid using the snapshot feature. Make sure your snapshots are stored outside of the Pi.
Whichever backup method you select, you will always have to restore the system image. Might as well re-install Debian and install Home Assistant, and restore your latest snapshot. It would take about the same time as restoring a full system image, or any other kind of total backup.
All-in-all, this is pretty far removed from the original topic.
Thanks for the prompt answer. I also hinted that the question is removed from the topic, but I thought it could be considered relevant for users with a similar installation.
Your recommendation seems sound, albeit not automated. And it involves completely shutting down the system for a relatively big amount of time, which I’d like to avoid. Unfortunately I don’t run only HA, thus I opted for a supervised installation, in order to be able to use Pi for other purposes too. So, I’ve tinkered a lot with Linux and other settings in my installation, which I wouldn’t want to lose in case the SSD fails.
I find it a little bit odd that a simple full backup of an installation seems so complicated in Linux, but then again I consider myself relatively unexperienced in this field yet.
well, doing a backup on a live system is tricky, on every OS.
If you’re willing to take chances regarding restorability, then you’ll be fine without shutting down, and you can automate.
If you want max restorability, you’ll need to shutdown & go manual.
You could also do smt like this : https://askubuntu.com/a/7811 … but the more you personalize your system, the less likely this will work as expected.
This is where hypervisors (Proxmox & co) really shine. Live backups, zero downtime, 100% recovery.
It all depends on how far down the rabbit-hole you want to go.
1 Like