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.
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.
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:
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
Could that be something messing it up? or is that just a label that the system gives the connection?
Maybe my post here helps?
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
@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.
can someone please take a look at this thread?
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
@Tamsy has already responded to you in that thread.
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?
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.
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.
My setup: Debian 11, OMV 6, Docker, Portainer, AMD64.
I already have docker and several container doing things on my NAS.
I use a custom storage location for my docker, so it is not my OS drive on my nas, but the replicated storage area.
When I follow this guide, it seems to reinstall docker & portainer and remove all my containers and stop them. They simply disappear. If I reverse all the steps and uninstall portainer and docker, then reinstall I get them all back right where I left off.
When I follow these steps the create user page starts, so I am assuming that the installation worked perfectly.
I think in the deb package it might be specifying the docker storage location and it is changing it. Does anyone know about this? This is a new NAS and a new install, and driving me crazy.