Hmm strange 
I never have problem with WiFi in Debian with my Raspberry pi 3.
I mainly use WiFi for my Pi too.
Mostly I have problem with Raspbian since Dhcpcd conflict with Network Manager but I able to manage this so I stick with Raspbian since I’m familiar with this.
However, HAS installation script are modify /etc/network/interfaces. you may need to check this, or try to not modify /etc/network/interfaces during HAS installation prompt.
I configured manually wifi connection via network manager. Restarted the interface and it got ip address. I didn’t try ssh though. Restarted the board and wifi is gone again. It’s super strange for me…
Indeed, I use Raspbian. And aptitude, which was going to remove Docker. So I marked it manually as ‘keep’. But I did not pin the version, so apt(itude) upgraded the Docker version.
Everything works now, except that HomeAssistant does not start by itself anymore. hassio_observer starts upon reboot, but I have to manually start the homeassistant container (or was it hassio_supervisor?). I try to understand how Docker works, and how the different containers that depend on each other do start each other.
It did work, before upgrading Docker, so I would like to use the original startup mechanism, but I cannot find much documentation about how this convenience scripts sets-up things. On https://www.home-assistant.io/installation/raspberrypi I read about using Docker-compose. Is that also what the convenience script uses?
Your help is very much appreciated.
There is a bug in docker-ce-cli in version 20.10.4 there is a link to a post with a fix here Installing Home Assistant Supervised on a Raspberry Pi with Debian 10
Raspbian is no longer a supported OS (hasn’t been for close to a year), so keep in mind you may run into issues with the HA Supervisor, update errors, etc. This guide specifically covers the use of Debian 10 on the Pi as well as using apt not aptitude, so YMMV.
Updated to new docker 20.10.5, and all is fine now. After a reboot, everything works.
Next time I configure my Raspberry SD with a new OS, I will use plain Debian, and not Raspbian then.
Still, it’s not completely clear to me how the framework of running Homeassistant supervised in a Docker container works, and how elements depend on each other. To be more specific: which should be started first, and then starts all the rest. I’m beginning to learn, but I could not find an overview somewhere.
Some of my questions may be more generic, but most of the answers may be specific for Homeassistant Supervised in a Docker container on a Rapsberry Pi (either running Debian 10 or Raspbian, that will not matter here I guess).
Q: “A container is based on an image. But when a new image of Homeassistant is installed, the settings, history, etc are maintained. How do I find where is the file (I suppose it is somewhere outside the container) to keep that recovers my complete home-assistant configuration and history and record? I guess that is a configuration option that is passed to the homeassistant container when that is started, but how do I retrieve that on a running system?”
A: I think I resolved this last question. I installed Portainer, and inspected the homeassistant container. And it shows that /data in the Docker container is mounted on (>Mounts>0>Source) /usr/share/hassio, where I can find a file homeassistant/home-assistant_v2.db. This must be the database, and the current configuration is indeed in configuration.yaml.
I cannot find, though, where the configuration is that tells that this is the location that is mounted in the Container, or is that a fixed location set in the image of homeassistant?
Did a fresh install and also had the issue with docker, downgraded as recommended and it started working fine afterwards, sans the power/SD access leds. Is that expected behavior on Debian? Any way to enable them anyway if so?
I do find it very odd I’m getting about 1.7GB of ram usage now while the exact same HA install plus octoprint and a few other things on top of the 64 bit RaspbianOS install I migrated from never broke the 1.2GB mark. Not sure on how I’d go about tracking down the reason, if anyone’s got any pointers they can share that’d be very much appreciated.
I gather everytime we do an OS upgrade now we’ll need to redo the docker downgrade? Well, until it is fixed at the source.
Didn’t work for me 
pi@chaletpi:~ $ sudo apt install docker-ce-cli=5:20.10.3~3-0~debian-buster
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '5:20.10.3~3-0~debian-buster' for 'docker-ce-cli' was not found
EDIT: This worked
apt install docker-ce=5:19.03.15~3-0~raspbian-buster docker-ce-cli=5:19.03.15~3-0~raspbian-buster
It was fixed at the source a few days ago. 20.10.5 is fine.
LOL, I just downgraded to 19,03.15. I guess I’ll update again.
Still doesn’t work for me (after a reboot)
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b5ea850f5a homeassistant/armv7-addon-configurator:5.2.0 "/init" 5 days ago Exited (0) 33 minutes ago addon_core_configurator
258398e869bc hassioaddons/portainer-armv7:1.3.0 "/init" 5 days ago Exited (0) 33 minutes ago addon_a0d7b954_portainer
8cf7e3ee0158 homeassistant/armv7-addon-ssh:8.10.0 "/init" 5 days ago Exited (0) 33 minutes ago addon_core_ssh
2085d4ae6823 homeassistant/armv7-addon-duckdns:1.12.4 "/init /run.sh" 5 days ago Exited (129) 33 minutes ago addon_core_duckdns
ab9bcda7e794 hassioaddons/sonweb-armv7:0.13.1 "/init" 5 days ago Exited (0) 33 minutes ago addon_a0d7b954_sonweb
353c19dae841 homeassistant/armv7-addon-mosquitto:5.1 "/run.sh" 5 days ago Exited (137) 32 minutes ago addon_core_mosquitto
a5f5a0376107 homeassistant/armv7-hassio-multicast:3 "/init" 5 days ago Exited (0) 33 minutes ago hassio_multicast
92b8ccc1a6f3 homeassistant/armv7-hassio-cli:2021.02.1 "/init /bin/bash -c …" 5 days ago Exited (0) 33 minutes ago hassio_cli
29cf57f016fc homeassistant/armv7-hassio-audio:2021.02.1 "/init" 5 days ago Exited (0) 33 minutes ago hassio_audio
f3f71e85d90b homeassistant/armv7-hassio-dns:2021.01.0 "/init" 5 days ago Exited (0) 33 minutes ago hassio_dns
8ceaa36b7e59 homeassistant/armv7-hassio-observer:2020.10.1 "/init" 5 days ago Up 2 minutes 0.0.0.0:4357->80/tcp hassio_observer
aa8eeb518073 be11a28f19e8 "/init" 13 days ago Exited (0) 34 minutes ago hassio_supervisor
2c9a3397b98c homeassistant/raspberrypi3-homeassistant:2021.2.0 "/init" 4 weeks ago Exited (0) 32 minutes ago homeassistant
EDIT: Actually, it’s even worst, now supervisor doesn’t stay loaded and doesn’t spawn the other docks Loading HomeAssistant manually, I never get the port opened.
EDIT 2: Went back to 19.03.15 and behaves the same
I’ve run into the supervisor/docker issue and have not been able to resolve it with the notes I’ve found here. I am attempting to install Debian instead of Raspian I had been using in a Pi4 to be compliant with supported systems. I am stuck at getting apt to work. “The value ‘buster’ is invalid for for APT” when trying to run any apt command while logged in as root. I’m sure I’m missing something obvious but I am sure after an hour and break and another hour that I am stuck. Help appreciated.
Maybe paste the command your trying to use?
I found the issue - Was using a never before used wall jack for ethernet that doesn’t work.
Sorry to bother for this
I am running 32bit Raspbian Buster on a Pi4 8gb. I have used this script before, and it worked fine. A recent power outage caused the Docker images to not load. In fact, this is not the first time, so I am looking into a UPS, or just be done with this Docker method.
I successfully removed the images, then ran this Kango-Who script to get HA back up and running. All was fine, until a reboot. All my settings, Mate desktop tweaks, themes, my Unifi Network controller, Samba share, Bluetooth manager, and lots more were gone. I have a feeling the author has snuck in this command, since the last time I ran it:
sudo apt install git-all
I doubt running this before running the script was the culprit:
sudo apt update && sudo apt upgrade -y && sudo apt autoremove –y
This command will ruin everything, and delete many Gnome parts of the system. Just look at this Ubuntu thread:
I keep backups, but hadn’t backed up my USB boot drive to SD in a few weeks. This problem happened before when I was following instructions for setting up a Wireguard container, so I know what happened when my entire desktop was gone upon reboot.
So, is the git command the culprit? Would this have happened on a plain Debian install?
Well, after recovering on the backup, then re-runnning the script, it worked. All I can think of is I might not have entered sudo -i first. Can’t see how that would strip all my settings and software off the system.
that the driver does not know how to drive the vehicle does not mean that the vehicle is bad, perhaps that vehicle is too much for that driver
I’m curious who that smartass comment is for? I posted a result of using this script. Using it stripped my system. I might have skipped sudo -i, but I’m not sure. Maybe running it on Raspbian is the problem. I’m not sure of that either. It’s worked before…
I’m hoping my post will help and enlighten anyone doing it the way I did. That’s what forums are for: to give and get advice. Telling people they shouldn’t even be attempting this helps no one. If your comment was for @realjax, why even bother? He needed to vent. He also can’t login via SSH. Either comment with help or don’t comment at all.
I’m sure there was a time when you knew nothing of this, and needed help. How’d it feel when some punk came on the thread and told you you weren’t capable of figuring it out?