No, it was fixed some time ago
Hm, any idea what could cause my problem?
I can start manually with docker start homeassistant hassio_supervisor but that’s annoying on every reboot.
Docker is v20.10.4. supervisor-2021.02.11.
Edit: downgraded via
sudo apt install docker-ce=5:19.03.14~3-0~debian-buster docker-ce-cli=5:19.03.14~3-0~debian-buster containerd.io=1.3.9-1
and now its working (and auto-starting) again. Maybe an issue with the very new Docker v20.10.4?
20.10.4 doesn’t look like it’s fully released yet. It looks different to how other releases look on github.
Docker v20.10.3 OK
Docker v20.10.4 NOK!
Just got 20.10.4 via an O/S (Debian) update and all is ok here.
What problem do you see?
As CodeFinder already mentioned it HA Supervised works with 5:20.10.4~3-0~debian-buster but it has to be started manually through CLI after a system reboot (docker start homeassistant hassio_supervisor). And it takes quite a while until it has fully loaded.
@ CodeFinder: You don’t have to go back to 5:19.03.14~3-0~debian-buster.
sudo apt install docker-ce=5:20.10.3~3-0~debian-buster docker-ce-cli=5:20.10.3~3-0~debian-buster containerd.io=1.4.3-1 is working OK and automatically starts homeassistant hassio_supervisor
1 Like
Well I didn’t reboot after the update and my reboot frequency is measured in months so I don’t know if it doesn’t start on boot but I would doubt it. Maybe a supervisor update to fix?
Obviously I spoke too early. Looking at the state of HA shows:
Therefore going back to 5:20.10.3~3-0 for now, keep docker-updates on hold for the time being until this is resolved.
That’s strange. Mind and dare to do a system reboot? 
Only after back to docker-ce=5:20.10.3~3-0~debian-buster docker-ce-cli=5:20.10.3~3-0~debian-buster here all is back to normal:
The difference seems to be supervisor-2021.02.12 (your system using beta channel) vs. supervisor-2021.02.11 on stable channel.
It wouldn’t be the first time a newer supervisor was needed…
Indeed 
So the conclusion as for now is not to update docker to 20.10.4 if HA is on update channel: stable with supervisor-2021.02.11.
+1 me too.
I noticed the same behavior on my test system. I thought it was because I installed the 2021.3 beta, but it seems it has to to with the supervisor version.
This PITA with Docker’s updates and Supervisor’s (strictly automatic) updates has to end. EVERY time the same thing.
I updated yesterday to latest Docker-ce, had the exact same behavior (supervisor starts only manually) and I almost ruined all my installation troubleshooting. This has to be red-flagged in the HA alarms immediately.
Reboot also takes almost 3-4 minutes, whereas it only took 30-45 seconds. Systemmd cannot stop the supervisor service effectively and it almost hangs.
I’ve somehow narrowed the problem to the following:
During boot (I’m not completely sure):
hassio-apparmor[343]: Warning: unable to find a suitable fs in /proc/mounts, is it mounted?
hassio-apparmor[343]: Use --subdomainfs to override.
hassio-apparmor[343]: [Error]: Can't load profile /usr/share/hassio/apparmor/hassio-supervisor
During shutdown/reboot (I’m positive-look at the timeline):
**Feb 27 19:40:50** systemd[1]: hassio-supervisor.service: Main process exited, code=killed, status=15/TERM
**Feb 27 19:42:20** systemd[1]: hassio-supervisor.service: State 'stop-final-sigterm' timed out. Killing.
Feb 27 19:42:20 systemd[1]: hassio-supervisor.service: Killing process 1450 (docker) with signal SIGKILL.
Feb 27 19:42:20 systemd[1]: hassio-supervisor.service: Failed with result 'timeout'.
Is it confirmed that reverting to the previous docker-ce version is a temporary solution? If so, can someone confirm the cmd in the terminal?
I’ve also tried with the beta supervisor (2021.02.12). It shows the exact same behaviour for me (not starting automatically upon restart, very slow shutdown).
OP’s link in installing Debian points to this dynamic URL here which is now showing 10.8. Since the guide insists we download 10.7, it should probably be updated. Note that I couldn’t find where to see older versions on that site, but I did find them here on a mirror site.
Docker 20.10.4
Debian 10.8
VMware machine on my PC
Installing succsesfuly with manual.
# curl -Lo installer.sh https://raw.githubusercontent.com/home-assistant/supervised-installer/master/installer.sh
# bash installer.sh
But after reboot container hassio_supervisor is Exited.
If I try
sudo docker start hassio_supervisor
thats works OK.
How can I fix autostart hassio_supervisor container after reboot?
The guide insists you use Debian 10, Debian 10.7 was the available version at the time of last update to the guide.
Use 10.8, or the available version at the time.
If also you experience a huge amount of errors logged by hassio_audio while it attempts to start, then try this solution .
Quickest way to confirm you have this problem is to see if hassio_audio returns a valid date:
# the date in hassio_audio is not set:
docker exec -it hassio_audio date
Sun - 40447 20480:16:-1227370880 -1225953501
# error in hassio_audio logs:
Assertion 'clock_gettime(CLOCK_REALTIME, &ts) == 0' failed
In addition, hassio_audio may cause audio to fail on the host device, and it can also cause an increase in CPU usage, up to 16% on my RPi 4.
Because it is not supported to run Home Assistant without hassio_audio, even when we don’t use it at all, one solution to work around these problems is to suspend PulseAudio running in the hassio_audio container when it is idle, and this can be done by loading the PulseAudio “module-suspend-on-idle” module. The shell script described below runs as service and will automatically load the module-suspend-on-idle module when the hassio_audio container is (re)started.
1 Like