Thanks! I just installed via ubuntu 20 as well
What’s the difference between this script and the official one here?
I’ve used the above on Ubuntu 18.04 LTS and it works perfectly.
1 Like
Since superviser version 2020.12.2 I’m noticing these warnings every ~2 hours:
20-12-04 02:50:21 WARNING (MainThread) [supervisor.host.network] Can't update connectivity information: Error: Timeout was reached
Does anybody also have these messages? Is there any way to fix them?
Not even one… (but I use Debian not Ubuntu)
I have them too, Ubuntu 18.04. Doesn’t seem to do anything because it’s running perfectly:
20-12-04 10:11:54 WARNING (MainThread) [supervisor.host.network] Can't update connectivity information: Error: Timeout was reached
20-12-04 10:12:34 WARNING (MainThread) [supervisor.host.network] Can't update connectivity information: Error: Timeout was reached
20-12-04 10:53:19 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state CoreState.RUNNING
20-12-04 10:53:19 INFO (MainThread) [supervisor.resolution.check] System checks complete
Ubuntu 18.04 on Intel NUC…
When i clean all docker hassio instances and start the script it works fine. It installs and works fine. But when i restart ubuntu, except for the hassio-observer, none of the containers start.
The services look like this:
xxx@xxx:~$ sudo systemctl status hassio-supervisor.service
● hassio-supervisor.service - Hass.io supervisor
Loaded: loaded (/etc/systemd/system/hassio-supervisor.service; enabled; vendor preset: enabled)
Active: inactive (dead)
xxx@xxx:~$ sudo systemctl status hassio-apparmor.service
● hassio-apparmor.service - Hass.io AppArmor
Loaded: loaded (/etc/systemd/system/hassio-apparmor.service; enabled; vendor preset: enabled)
Active: active (exited) since Thu 2020-12-10 13:37:07 +03; 1min 47s ago
Process: 993 ExecStart=/usr/sbin/hassio-apparmor (code=exited, status=0/SUCCESS)
Main PID: 993 (code=exited, status=0/SUCCESS)
So i try starting hassio-supervisor or hassio-apparmor services manually. This time supervisor container runs but all other hassio containers are deleted from docker automatically.
I upgraded Ubuntu from 18.04 to 20.04. Still same response.
How can i troubleshoot more? Thanks.
UPDATE: Found the problem, newly updated docker 5.20 is the culprit. Returned back to 5.19 and everything is fine.
Please check 2 Servers 2 Locations, both running HA, both quit working after recent server update
I was running into the same issue anyone find a working solution?
After quite some work; i managed to handle it this way:
- Upgrade Ubuntu to 20.04
- Downgrade Docker to 5.19
- Run the script in this page and answer ‘y’ to network question:
https://github.com/home-assistant/supervised-installer - Wait for all containers to be formed in docker
- Restart
- Since all supervisor addon containers are disappeared in docker (at least in my case), in ha supervisor addons page, copy addon configuration, uninstall it, install it back again, paste configuration and start addon.
Those solved my problems.
2 Likes
Also had the same issue on ubuntu 18.04 and intel nuc (was running this setup for 2 years). got it working by downgrading docker but this setup doesn’t feel stable to me anymore. So i decided to completely revamp my installation and run home assistant in a VM on debian buster because i run more docker containers then just some home asssitant addons and dont like the way this is going with dependency’s.
It will be the same for Debian in this case.
3 Likes
Ah i missed that alert but the docker issue isn’t the only reason to switch the setup also debian buster is the supported OS according to this 0014. Installation method: Home Assistant Supervised.
1 Like
I kind of wish Ubuntu WAS supported, I think there are a LOT more people running Ubuntu in their homes than Buster. I know we can run in a VM, but it seems like that would consume more energy than Docker.
So my Docker upgraded yesterday to said docker version. I didn’t reboot the host, just restarted the supervisor service and it seems fine. Just updated to 1.0.0b4 and still ok. A VM I play with crashed though and I didn’t try to fix that yet.
Any idea when docker 20 will be supported? I bet what saved me is my pathological resistance to ever rebooting the host and if I did reboot it I bet it will be broken.
EDIT: Running those commands downgrading docker on my VM fixed that proxmox one.
1 Like
To disable update to docker version 20, access the debian host and then run
echo "docker-ce hold" | sudo dpkg --set-selections
echo "docker-ce-cli hold" | sudo dpkg --set-selections
Docker is reverting the change regarding systemd so that’s one part to wait for. https://github.com/docker/docker-ce-packaging/pull/511#issuecomment-742538970
https://github.com/moby/moby/pull/41773
And then when that’s done a new supervisor release will have a fix.
4 Likes
Thanks for the info…
This also seems to work.
sudo apt-mark hold docker-ce docker-ce-cli containerd.io
I see this often but I don’t see anyone showing it and it doesn’t sound correct. Your install is going to use whatever it uses…
It’s pretty easy to create a KVM VM of HA OS using virtual machine manager and assign whatever resources you like. The only “difficult” bit is making a bridge network for it so that the VM gets an IP through DHCP like any other device on your network. But I was able to use a couple of the methods given here for that. https://www.tecmint.com/create-network-bridge-in-ubuntu/
Oh, and the VM is going to be using docker because…surprise!..It’s always used docker whether on a pi, nuc, tinkerboard, odroid, or a VM. Running it with docker was never a choice. The choice has always been which Operating System to use.
1 Like
Yes I just chose the first option on this page, which seems to give 4 alternatives. https://askubuntu.com/questions/18654/how-to-prevent-updating-of-a-specific-package
2 Likes