Moved over to Debian with Docker today from home assistant OS on RPI4. This guide was the bee’s knees. I used the backup and restore documentation. Things started up slow at first but seem to have stabilized and back to normal. Thank you so much for this write up 
1 Like
I have been having an issue after going to docker. I ran Mosquitto broker add-on in home assistant and after reboot it does not start properly. If I go to add-on and restart broker things work fine until next reboot of home assistant or host. does any one have any suggestions? Should I maybe run the broker in a separate docker container?
Have you select in Mosquitto broker add-on :
Start on boot Make the add-on start during a system boot
yes I did. it is very strange.
Hello HomeAssistant Gurus,
I used this guide to install HA supervised on my new Raspberry Pi4. I didn’t want to flash my SD card with HASS at the first place because I am already running motion eye on the same Pi. The installation went well, but I am unable to bring up the UI. I don’t see anything running on port 8123 on the pi.
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 5.10.11-v7l+ #1399 SMP Thu Jan 28 12:09:48 GMT 2021 armv7l GNU/Linux
I see only the following warning when I run ha supervisor logs
21-02-18 02:51:26 WARNING (MainThread) [supervisor.store.data] Can't read /data/addons/core/vlc/config.json: Service vlc_telnet not found @ data['discovery'][0]. Got 'vlc_telnet'
21-02-18 02:51:26 WARNING (MainThread) [supervisor.addons.validate] Add-on config 'auto_uart' is deprecated, use 'uart'. Please report this to the maintainer of ESPHome
21-02-18 02:51:26 WARNING (MainThread) [supervisor.store.data] Can't read /data/addons/core/vlc/config.json: Service vlc_telnet not found @ data['discovery'][0]. Got 'vlc_telnet'
21-02-18 02:51:26 WARNING (MainThread) [supervisor.addons.validate] Add-on config 'auto_uart' is deprecated, use 'uart'. Please report this to the maintainer of ESPHome
I ran ha supervisor repair a couple times with no luck.
I assume the following messages with dmesg is normal.
[ 51.347271] Bluetooth: RFCOMM TTY layer initialized
[ 51.347291] Bluetooth: RFCOMM socket layer initialized
[ 51.347318] Bluetooth: RFCOMM ver 1.11
[ 67.523105] hassio: port 5(vethb30af4a) entered blocking state
[ 67.523123] hassio: port 5(vethb30af4a) entered disabled state
[ 67.525920] device vethb30af4a entered promiscuous mode
[ 67.804625] IPv6: ADDRCONF(NETDEV_CHANGE): veth3e37713: link becomes ready
[ 67.804848] IPv6: ADDRCONF(NETDEV_CHANGE): vethb30af4a: link becomes ready
[ 67.804944] hassio: port 5(vethb30af4a) entered blocking state
[ 67.804956] hassio: port 5(vethb30af4a) entered forwarding state
[ 70.117164] hassio: port 5(vethb30af4a) entered disabled state
[ 70.131511] eth0: renamed from veth3e37713
[ 70.201778] hassio: port 5(vethb30af4a) entered blocking state
[ 70.201792] hassio: port 5(vethb30af4a) entered forwarding state
Any hints/help is appreciated!!
I’am installing an odroid-c4. In the “Supported Machine types” I currently only see
- intel-nuc
- odroid-c2
- odroid-n2
- odroid-xu
- qemuarm
- qemuarm-64
- qemux86
- qemux86-64
- raspberrypi
- raspberrypi2
- raspberrypi3
- raspberrypi4
- raspberrypi3-64
- raspberrypi4-64
- tinker
Should I just pick odroid-c2 as machine type or another option in the list ? What are the consequences ? Why does it matter ?
The image will be optimised for the hardware = why it matters. I would think the C2 one would be the best choice…
I have a feeling the latest docker update or debian update has screwed things up. But I could be wrong.
I used the old method in the past which is decrepated. But when I updated the OS my HA installation got broken. Docker container 'supervisor’didn’t start anymore. Also rebooting took a very long time.
So I found this guide and decided to start over because this version has a ‘supported’ lable. However I followed the exact steps as above. Everything works fine untill I reboot.
HA doesn’t come back anymore. When checking out the container status nothing was up. I can start them manually and it works fine.
Can anyone confirm or have a solution for me?
oh and I did ‘docker update --restart unless-stopped $(docker ps -q)’ and most containers do start now except supervisor. Also reboot takes a long time. I have a ping session open and takes about 1-2mins until it really goes offline.
After reboot with above command i get this
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
396f2dd272e5 homeassistant/aarch64-hassio-multicast:3 "/init" 13 minutes ago Up About a minute hassio_multicast
2ddb6734e110 homeassistant/aarch64-hassio-audio:2021.02.1 "/init" 13 minutes ago Up 59 seconds hassio_audio
b20c97ac2850 homeassistant/aarch64-hassio-dns:2021.01.0 "/init" 13 minutes ago Up 59 seconds hassio_dns
573d1cb43c3f homeassistant/raspberrypi4-64-homeassistant:2021.2.3 "/init" 28 minutes ago Up About a minute homeassistant
c0e4e8e5ac15 homeassistant/aarch64-hassio-observer:2020.10.1 "/init" 29 minutes ago Up 59 seconds 0.0.0.0:4357->80/tcp hassio_observer
0ff5fe31c01d homeassistant/aarch64-hassio-cli:2021.02.1 "/init /bin/bash -c …" 30 minutes ago Up 59 seconds hassio_cli
932e887a11f8 homeassistant/aarch64-hassio-supervisor "/init" 30 minutes ago Exited (0) 2 minutes ago hassio_supervisor
Only HA is having issues because other docker apps I used restart fine after a reboot
I read some posts about downgrading to docker 19, no idea if this fix your problem.
But how did you update your OS? Did you perform a fresh install by following the the tutorial or is there an easier way to go from raspbian to debian?
No, my original installation was on raspian (decrepated instructions) where I did an apt-get upgrade / update cycle. Usually this doesn’t cause any issues. But I did notice a docker update passing by which was released earlier this week.
Because I already had some unexplained issues with the rpi I decided to start blank and followed above instructions. Seeing that this was a blank install I stumbled upon the same problems I had with my original installation. Supervisor not starting anymore after reboot but able to start it manual and things work fine then.
I’m in the same boat with you, just screwed up my HA after update Raspbian.
Try many way (include reinstall) until roll back docker-ce to version 19.
apt install docker-ce=5:19.03.15~3-0~raspbian-buster docker-ce-cli=5:19.03.15~3-0~raspbian-buster
That’s it, reload Raspbian and supervisor back to start automatically !
4 Likes
I installed Docker using the convenience script. Now, when I run Aptitude to keep (the rest of) my system up to date, it suggests to remove docker-ce, docker-ce-cli, and containerd.io with the remark “packages being removed because they are no longer used”. I guess this happens since the installed versions have been superseeded by an upgraded version, but the convenience script did install the packages without marking the correct dependencies.
What should I do?
- mark the package docker-ce as manualy selected in aptitude (the other two depend on this one) so they are kept
- just upgrade, let aptitude remove them, and suppose that they are kept because they were not installed through apt anyway
The 1st option seems most safe.
Update: I did the first, and upgraded all with aptitude, after manually selecting the “docker-ce” package. At first, HASS did fail. But after a reboot, and some patience, everything is working again, and now it’s all running fine.
So maybe, as an additional step in the installation process, after running the ‘convenience script’, one should select docker-ce via apt, apt-get, or aptitude, or whatever package maintenance utility is being used.
Aaah thanks.
Just did it and everything is back to normal again luckily.
thank you
1 Like
This isn’t required as the docker install script pulls and installs the current/latest version.
It seems there is again an upstream issue with docker-cli causing an issue with the HA Supervisor. Downgrading docker-cli seems to fix this.
or as you have done downgrading to 5.19.x
4 Likes
But that is for the first install. Then you get the latest version. But upgrading Docker means the host version of Docker, not Docker in a Docker container. And the Docker installation on the host is managed by the host’s package management system, like apt or aptitude. And (at least on my system) aptitude was thinking Docker was no longer needed, when it started checking and noticed the version was outdated.
That is what I’d like to solve.
What are you on about?
If you install Docker on the host using the script, that’s all you need to do to run HA Supervised. You don’t need to update the Docker environment of a HA container.
I don’t have this issue on my test system using apt. Perhaps that’s an issue with Aptitude.
I think maybe he’s using raspbian and the docker convenience script? I think that has a different update method than apt-get etc? I could of course be totally wrong lol.
Hi there! Thanks for writing these instructions. I just followed all the steps and everything looks good except that wifi is not working anymore. I really wanna connect PI to wifi and I understand the risks and that LAN is more stable. During setup wifi was working fine, looks like HA’s installation script has blocked wifi interface or smth. Could anybody help me please?