I have figured it out.
When I was starting manually hassio_supervisor, the docker threw the following error:
setting cgroup config for procHooks process caused \\\"failed to write a *:* rwm to devices.allow: write /sys/fs/cgroup/devices/docker/...
I do not know if anyone needs this info, but anyway:
lxc config edit ubuntu-lxd-3
raw.lxc: |-
lxc.cgroup.devices.allow = a
lxc.mount.auto=proc:rw sys:rw
lxc.cap.drop=
lxc.apparmor.profile=unconfined
EDIT:
This is my final configuration ( a fragment):
raw.lxc: |-
lxc.cgroup.devices.allow = a
lxc.cap.drop=
lxc.apparmor.profile=unconfined
security.nesting: "true"
security.privileged: "true"
While I was troubleshooting this issue, I have installed hassio on QEMU/KVM and can confirm that it works on this platform, as well.
UPDATE:
docker container homeassistant
doesn’t start automatically for some reasons, I had to start it manually, others two are ok. Will be running it on QEMU/KVM.
UPDATE 2:
LXD/LXC container:
docker update --restart=always homeassistant
did the trick.
Now it is starting in both cases: the lxc container reboot (before it stopped on reboot) and systemctl restart docker
.
On QEMU/KVM homeassistant container starts on VM reboot but stops on the docker service restart (so the fix is the same).
CONCLUSION:
hassio is not going to work on LXD container in normal way. All add-ons in hass.io are docker containers which do not start automatically after a container reboot. It can be fixed by docker update --restart=always <add-on-container-name>
applied to each container but this is a bit cumbersome.
On QEMU/KVM VM they start on the VM reboot, but fail to start on the docker service restart. That is not good, but I can live with it. So my choice is a KVM machine (at least this is a full virtualization and my host is safe).