@JoFie I have a snapshot, i just restored from it. HA runs on RP3 SD card, somewhat new card. Before restoring it worked fine on same SD but as HA OS, now it’s Rasbian OS and HA Supervised in Docker.
Did someone of you tried to
pause supervisor
remove hassio_audio:2021.2.1
pull hassio_audi:17
tag hassio_audio:17 with hassio_audio:2021.2.1
start supervisor
??
I restored my installation and I don‘t want to restart it, so I can’t try myself.
I confirm the same problem. Raspberry Pi 3B, Home-Assistant Supervised in Docker on Raspbian (HA 2021.1.5, Superviser 2021.02.11). And yes, it all started after updating and rebooting. The log for 12 hours already takes 195 MB.
And, like many others, I don’t use audio at all
I can try. But please describe in more detail what commands I should enter, I’m not very good at Linux and Docker yet
Do you have Portainer installed?
Yes, but haven’t updated it for a long time. Currently installed version 1.23.2
Try to pause the supervisor and delete hassio_audio.
Have a look if it stays away or if the supervisor reloads it.
OK, I’ll try in an hour.
Maybe disabling audio in /boot/config.txt will solve the problem? For example, as described here https://radio-docs.netlify.app/docs-audio
I tried your recommendation to load an earlier version of hassio_audio, and it works!
As expected, it takes a little bit before the (new) hassio_audio container is started, but now HA fully works, including the “Supervisor” screen.
Below are the commands I executed, if others want to try.
docker pause hassio_supervisor
docker stop hassio_audio
docker container rm hassio_audio:2021.2.1
docker rmi <image ID>
docker pull homeassistant/armv7-hassio-audio:17
docker tag homeassistant/armv7-hassio-audio:17 homeassistant/armv7-hassio-audio:2021.2.1
docker unpause hassio_supervisor
You can get the image ID using: docker images
Interestingly after the tag change I now have two images, the downloaded version “:17” and also a new image with tag “2021.02.1”.
The danger here is that when the HA folks release a new hassio_audio version in which this problem is not fixed, the Supervisor will download it automatically in the background and the SD-killing problem will be back.
That was too quick… 
The hassio_audio container stopped after a while, and I see the following errors once a minute in the Supervisor logs:
21-02-21 16:20:58 INFO (MainThread) [supervisor.plugins.audio] Starting Audio plugin
21-02-21 16:20:58 INFO (SyncWorker_3) [supervisor.docker.interface] Cleaning hassio_audio application
21-02-21 16:21:00 INFO (SyncWorker_3) [supervisor.docker.audio] Starting Audio homeassistant/armv7-hassio-audio with version 17 - 172.30.32.4
21-02-21 16:22:00 WARNING (MainThread) [supervisor.misc.tasks] Watchdog found a problem with PulseAudio plugin!
21-02-21 16:22:00 INFO (MainThread) [supervisor.plugins.audio] Starting Audio plugin
21-02-21 16:22:00 INFO (SyncWorker_3) [supervisor.docker.interface] Cleaning hassio_audio application
21-02-21 16:22:01 INFO (SyncWorker_3) [supervisor.docker.audio] Starting Audio homeassistant/armv7-hassio-audio with version 17 - 172.30.32.4
It knows it is version 17.
Last error in the Audio logs:
[cont-init.d] executing container initialization scripts...
[cont-init.d] alsa-mixer.sh: executing...
[17:25:06] INFO: Adjust ALSA mixer settings for /dev/snd/controlC0
[17:25:07] INFO: Adjust ALSA mixer settings for /dev/snd/controlC1
[cont-init.d] alsa-mixer.sh: exited 0.
[cont-init.d] pulse-config.sh: executing...
[cont-init.d] pulse-config.sh: exited 0.
[cont-init.d] setup-filesystem.sh: executing...
mount: permission denied (are you root?)
[cont-init.d] setup-filesystem.sh: exited 1.
[cont-finish.d] executing container finish scripts...
[cont-finish.d] done.
[s6-finish] waiting for services.
[s6-finish] sending all processes the TERM signal.
[s6-finish] sending all processes the KILL signal and exiting.
I saw that @JoFie had already tried replacing hassio-audio with a previous version and did not try. I tried to disable audio in /boot/config.txt, but no result
Please, everybody with this fault… type
sudo docker exec -it hassio_audio date
and post the output.
Sun - 40447 20480:16:1993017536 +1994436387
If I am right, the fault traces back to the broken system time inside the container…
For me, hassio_audio:2021.02.1 is running now after restoring my backup.
It shows the correct system date and time.
Yesterday, the error came back after a restart and the system time was broken…
At the moment I have no idea why this happens.
After some research I think it is a problem with alpine 3.13 on armv7…
Could you please try to ping something?
sudo docker exec -it hassio_audio ping 8.8.8.8
If the ping should work, you can cancel with ctrl+c
But I think you will also get an clock error…
Culprit seems to be musl 1.2 in alpine 3.13
https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.13.0#musl_1.2
Yes, you are right
ping: clock_gettime(MONOTONIC) failed
1 Like
The problem:
Therefore, the following platforms are not suitable as Docker hosts for 32-bit Alpine Linux 3.13.0, due to containing out-of-date libseccomp: Amazon Linux 1 or 2, CentOS 7 or 8, Debian stable without debian-backports, Raspbian stable, Ubuntu 14.04 or earlier, and Windows. This applies regardless of whether the Linux distribution Docker packages or separate Docker package repositories are used.
Perhaps a solution:
In order to run under old Docker or libseccomp versions, the moby default seccomp profile should be downloaded and on line 2, defaultAction changed to SCMP_ACT_TRACE , then --seccomp-profile=default.json can be passed to dockerd, or --security-opt=seccomp=default.json passed to docker create or docker run . This will cause the system calls to return ENOSYS instead of EPERM, allowing the container to fall back to 32-bit time system calls. In this case, the container will not be compatible with dates past 2038.
Alternatively, --security-opt=seccomp=unconfined can be passed with no default.json required, but note that this will reduce the security of the host against malicious code in the container.
2 Likes
Ping and date from my RP3
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: clock_gettime(MONOTONIC) failed
Sun - 40447 20480:16:1993161344 +1994579747
I’m not so familiar with coding and don’t know what to do with your answer.
1 Like
I think, we figured out the problem.
Now we need a solution, but I am not an developer 
Just a little Sherlock 
Easiest would be the developers will build the new hassio_audio on alpine 3.12 again.