Look at Section 4 paragraph 3 within the OP.
Somewhere around Section 2.1 the guide needs to be updated.
Debian is now shipped with ifupdown. This will interfere with network manager.
If the following message is shown when installing network manager:
The following network interfaces were found in /etc/network/interfaces
which means they are currently configured by ifupdown:
- eno1
If you want to manage those interfaces with NetworkManager instead
remove their configuration from /etc/network/interfaces.
Then the file: /etc/network/interfaces needs to be edited. In my case the lines with eno1 (my ethernet) needs to be commented out, before proceeding. If this is NOT done, the machine will crash and nothing will work.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eno1 <-- This should be commented out
iface eno1 inet dhcp <-- This should be commented out
Remember to reboot before proceeding.
1 Like
ifupdown has been shipped with Debian since ages (a quick lookup brought me back to Debian 8 Jessie (released April 2015).
I don’t know what went wrong with your installation to show that described message. Just last week I installed a new Mini PC using this excellent guide and all went smooth without any errors.
I followed kanga_who’s guide step-by-step except for:
apt-get install ... avahi-daemon ...
because the requirement for Avahi was superseded in favor of systemd-resolved within the supervised-installer beginning with version 1.1.1.
Having avahi-daemon and systemd-resolved.service active leads to unexpected errors when starting Supervisor. David started a extended thread about the latter here.
Going back to the topic, did you remove the wired eth0 after installing Debian (after Section 1) and continued with Section 2 of the guide by using WLAN? There are indeed reports about ifupdown seemingly freezing the boot process for quite some time if no Ethernet cable is plugged in but this should has already been fixed ages ago according to the bug reports.
The comunity guide suggests to continue remotely only after having completed Section 3.2 which in my understanding should be the earliest to remove the wired connection and continue remotely which can also be through WLAN (which is discouraged all over the forum anyway).
Other than the above the whole installation process is working flawlessly as long as one strictly sticks to Jason’s guide as I just went through the whole process (except for installing avahi-daemon) a couple of days ago.
2 Likes
I’ve used to run Debian on my RPI4 and have never seen ifupdown on that. Could be that the vanilla Debian for RPI don’t ship with ifupdown?
I’ve always been running wired. As soon as the HA install is finished, the connection dies and I get a ton of DNS errors in the log, but if I comment out those two lines, everything is working perfect (except I can’t set a fixed ip in the frontend)
So I should just omit the avahi? or is there anything else to be installed instead?
Thanks for reminding me, need to update the guide. 
2 Likes
Definitely. Probably that will also fix those DNS errors you are describing without having to tamper with “interfaces”:
Since we are using systemd-resolved the reversal conclusion is to disable/remove the avahi-daemon:
Dependencies updated
1 Like
That didn’t help unfortunately 
Don’t know if this has something to do with it
--- version.home-assistant.io ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 6.426/6.426/6.426/0.000 ms
Device "eno1 <-- THIS
eno1" does not exist. <-- AND THIS
[info] Install supervisor Docker container
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the 'ha' cli
[info] Switching to cgroup v1
When I list the nmcli, I can see that’s renamed to Supervisor eno1
Could that be something messing it up? or is that just a label that the system gives the connection?
Ok, as I’ve got some clearance on how to resolve healthy/unsupported, I still would like to know how I would get the docker-compose installed without breaking my NetworkManager?
@kanga_who are you able to assist me on this? Great tutorial by the way 
No, I don’t use it and it’s out of the scope of the guide.
Thanks
can someone please take a look at this thread?
summary:
Installed HA using this but I have a problem with the IP address assignment.
Once I installed Debian 11, IP is being assigned by my modem without any issues (tried host restart too), but once I install HA and restart the host, it is not being assigned an IP address. Solved this by assigning a static IP address, but DNS is still not working.
Any help would be appreciated
yeah he is very helpful… but did not work but now i am seeing that he replied again. will check again later on cause i am out now. also any ideas related why the nuc is not getting an ip from the modem once ha installed?
Why (If I have home assistant supervised) I can’t update my Open Media Vault, Docker and Portainer?
Any solution to this issue?
Why not . ?
If supervisor detects any containers running which were not created and started by it then it marks your system as unsupported. So if your goal is to remain on a supported system I’m not sure what value there is in installing docker-compose. Even if you manage to figure out a way to get it installed on a supported system, all the things it can do will mark your system as unsupported. Seems like a futile exercise but maybe I’m missing something.
The system always say internal error. Always when I update docker, when it’s finishing the update, say restarting docker, restarting portainer, restarting home assistant, error encountered home assistant supervised. Internal error. And after that stop. I can use the docker, portainer and open media vault but it is impossible to update.
Im going to try to install promox and make 2 virtual machines, one for home assistant and another for the rest.
Hi Mike,
Reason for asking is that I want to run Frigate in a separate container rather than using the addon due to some configurable parameters not available within the addon.
I’ve now installed docker-compose and it works perfect (though as you say, marks HA as unsupported). But I assume I can use the command to do any updates even if marked unspported, ref 4) in the instructions.
Possibly. It’s unsupported so not really sure what will or won’t work. There is no testing is done on unsupported configurations, automated or manual. You’re welcome to run that way but generally speaking you now are sole support for your installation, home assistant does not provide it anymore.
If this was all just for one addon missing a few options did you consider just adding those options? As a PR to frigate preferably but if you aren’t comfortable with that you can simply fork it and modify it’s config file in your fork. Then add your fork as an addon repo instead of the normal frigate one and install from there. Maintenance is mostly likely just rebasing from the upstream periodically.
Or if you find the fork impractical for some reason (maybe if it has a lot CI that doesn’t work in your fork or something) then just clone frigate into your /addons folder and modify it there. Any addons in that folder are treated as local addons. HA will build the image and attach it to a container according to its config.yaml like any other addon.
Each of these latter two options will still result in frigate being run with your desired config but your system will still be supported. The only thing you’ll be fully responsible for supporting is your addon (and even then only if you can’t reproduce issues you encounter in the normal frigate addon). But it’s your call, whichever you prefer.
1 Like