Installing Home Assistant Supervised using Debian 12

This guide is not for installation on a Pi, I linked you to the correct guide for that previously.

None that I am aware of. The normal use case is you access HA from a web browser on your phone, laptop, tablet, PC etc - not from the HA machine itself.

Just following through and at first step of HA install I get
“Package Network-manager is not available but is referred to by another package…”
“Package apparmor-utils is not available…”
and a cascading fail from there…

Any ideas?

Edit… after browsing some other instructions it would appear that network-manager doesnt have a package for x86 and only 64bit, so think i’m bang out of luck on this machine

Just wanted to check back in and say thank you.

Once I have forsaken my touch screen, I followed your guide to the letter and it didn’t fail to deliver.

Thank you for doing the extra mile for us folks whom need explaining like we are 5.

I hope that someday in the future we will get support for raspbian derivative , but now I understand that it’s not that trivial.

1 Like

Not a worry mate, I still get confused by HA regularly, even after using it for over 3 years.

Thanks for your work on this, any ideas? 10.6 debian fresh install.

EDIT fixed it… doh…

i’d installed docker manually, which I assume must do something with apparmor, started again and it was fine

at least mention what was wrong, it might help others.

First time using docker and this tutorial straight forward into making a functional home-assistant without hassle! Really thanks @kanga_who

Also for another user that build from very minimal linux distro (mine from debian-netinst without installing any additional components on setup phase), if you setup network using editing


I encourage you to install and setup network using network-manager before running the script, because the script will move to using that manager in the setup process.


I just spent some time migrating from Ubuntu to Debian. I had problems with getting a USB-to-serial device to work. After a frustrating afternoon, I found a process used for braille devices was grabbing the tty port. Here are the the CLI commands I used to remove it:

sudo apt-get remove brltty
sudo  apt autoremove

The second command clears out a few dependency files. After a reboot, all was back to normal.

Thanks for the tutorial.


I know this isn’t technically the purpose of this guide but it is related…

Have you ever looked into how to completely remove the supervised install from Debian?

I haven’t been hit by the “unhealthy” bug/feature yet on my test Supervised install but if I do then there won’t be any further purpose to keeping it around so I might as well remove it when it finally happens. But I’ve never seen anywhere on how to actually uninstall it.

1 Like

The only way I have found to do that (and there is probably a better way) is to use docker commands to untag the Supervisor so it doesn’t continue to restart/re-install when deleted, and then force remove all the HA containers one by one.

The first time I tried to uninstall it a while back there was also a system service that needed to be stopped and then I just removed all of the docker containers and it did stop everything from loading again.

But it just doesn’t give me a warm fuzzy that all of the things that were installed are still hanging around somewhere and never properly uninstalled. It has to install other stuff besides the system service on the OS itself outside of all the containers or they wouldn’t make such a big deal about what OS’s are supported. I guess I could dig into the script to see what is installed and decide at that point if it’s worth cleaning everything up.

It’s like trying to make sure that programs are completely uninstalled in Windows. It seems like there are always bits and pieces left behind that pop up later and bite you somehow.

1 Like

Yeah, I get where you are coming from. I found that I had to untag the supervisor container before removing it, or it automatically re-installs itself.

That, plus deleting the /config directory seemed to remove everything.

I’m not sure what that means.

Something like this.

sudo systemctl stop hassio-supervisor.service
sudo docker rmi -f homeassistant/aarch64-hassio-supervisor:latest

Ah, OK. So it looks like it just completely removes the container and the associated image. I think.

I’ve been wrestling with Debian the past few days. There were still problems with my installation. Somehow, I managed to mess up booting with a running NetworkManager. I could start it manually after a boot, but after spending some time trying to get it working, it seemed easier just to reinstall everything. In going though the exercise again, I have some observations:

I found it difficult to install the correct driver for my network device (Realtek rtl8168g). The interface worked well enough for the installation process, but it complained at every boot. I also have an Intel processor that wants some firmware (or microcode), presumably to mitigate the Spectre/Meltdown security vulnerability. It turns out that 3rd party drivers are designated as “non-free” and are not included in the basic installation images <>. There are various ways of finding the right driver, but they’re typically aggregated by manufacturer into larger archive files which need to be moved over and somehow installed. Without a fully configured system, it becomes cumbersome. The good news is there’s a way of getting a distribution with the non-free binaries included. They’re here:

This is the one I wound up using:

The second observation is that when I installed the latest distribution, it did not allow me to skip the installation of the Package Manager. The installer plows ahead without offering up a choice. I’m not sure what this does to the HA installation guidelines.

My next observation relates to a post I made two days ago. When installing the OS, I saw a specific reference to brltty during the installation. It seemed out of place and I suspected that leaving the USB-to-serial cable connected to the system might’ve triggered it. Before proceeding with the HA installation, I reinstalled Debian with the cable disconnected and my hunch was correct; no brltty process was running after the installation was complete.

My last observation is an issue still unresolved. While HA responds to the CLI, the HTTP sever doesn’t provide a browser interface. I get this information at boot time:

[    4.184767] systemd[1]: Found ordering cycle on hassio-supervisor.service/start
[    4.184776] systemd[1]: Found dependency on docker.service/start
[    4.184783] systemd[1]: Found dependency on
[    4.184791] systemd[1]: Job hassio-supervisor.service/start deleted to break ordering cycle starting with

This is the only issue I see in dmesg. Unfortunately, I don’t know where to go with the information. Any help would be appreciated.

Edit: ‘docker stats’ shows this message:

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/version: dial unix /var/run/docker.sock: connect: permission denied

Im running HA supervised on an ASUS “nuc”. I’m using an m2 SSD for the OS and all installations and a normal HDD for storage. I would like to move my HA database to the HDD, which is mounted under “storage”, but HA keeps telling me that “the recorder component couldn’t be set up” when trying to follow the documentation. The home-assistant_v2.db is normally found in /usr/share/hassio/homeassistant/, and I would like to run it from the /storage/hass_db/ folder. Adding db_url: sqlite:////storage/hass_db/ under recorder: in my config file doesn’t help.

After asking around I understand that the docker container doesn’t have access to folders outside the “homeassistant” folder, and that you specify accessible folders when setting up the container, which I have experienced while setting up e.g. PLEX.

Since I installed HA supervised using the script in the topic, is there any other way to “add” folders to the container in retrospective? Would it be possible to create a symlink instead, or would the problem remain since a symlink is a shortcut to the folder HA cant access?

What’s your experience?

I hope to get some help troubleshooting a “refused to connect” after following this install guide. I made it to the end with the only error referring to [warn] Changes are needed to the /etc/network/interfaces file". I answer yes to overwrite and get [info] First setup will take some time, when it’s ready you can reach it here: Waiting more than an hour, the connection is still refused from my Win10 PC. I can connect to the system with Putty/SSH and can issue the ip a and sudo docker ps commands. My LAN connection is enp5s0 and the ip address matches the the one produced by the install script. The two docker containers installed are hassio observer and supervisor. “Hello World” works. Looking at the interfaces file with nano, it is empty. Out of desperation, I added the 8123 port to ufw, which didn’t work. I also disabled ufw which also didn’t allow me to connect. What else can I check?

If you have just done a fresh install today, then you most likely have encountered the issue between the recent Docker 20.x update and HA Supervisor.

Try these steps.

sudo apt remove docker-ce
sudo apt autoremove --purge -y
sudo reboot

When the machine comes back online;

sudo apt install docker-ce=5:19.03.13~3-0~debian-buster
sudo reboot

If this is successful, do not do any OS updates until the Supervisor update comes through to address the Docker 20.x issue.

You may also need to re-run the installer script.

sudo -i
curl -sL "" | bash -s

Actually, it was my third “fresh” install of debian today, lol.
Thank you for you quick reply and suggestions. It worked and I’m able to log in through the user interface. I don’t remember why I installed ufw, it wasn’t included in the distro; should I keep it? I’m trying to maintain a minimal “well documented” install of debian and home assistant in an effort to minimize future complications.