Because of this and previous comments. Perhaps I’m misunderstanding.
You’re both right. Op should probably use the other guide. But nevertheless this is a DNS issue. Fix that or nothing works
I’ve seen this before, and it turned out to be a IP6 dns issue, so maybe try again using IP4 only?
Thx all. A couple things. I appreciate the comment about dual booting not affecting anything since when booted to Debian, it can’t see the other partitions. I want to use supervised for several reasons. I’m trying to relearn skills I forgot in the 80s so I greatly appreciate this community!!
So, overnight I DID wipe my entire hard drive yet again and then used the latest Debian installer, selecting the non GUI version. I partitioned the drives successfully and got through the debian issue by using this command: sudo apt install docker.io. That doesn’t need DNS since it was already in the repository.
But several of you are correct that is was a DNS issue. Now the key command to Home Assistant · GitHub … failed with a similar message about unable to resolve host. I have been trying to find a link for fixing DNS issues in plain language. LOL! I’ll keep searching, but if someone can help, I would apprciate it!
apt does use dns because it downloads from a repository.
Actually, i had the same (even in this post 
)
Anyway, i found supervised too strickt, i couldn’t run some other stuff i needed (as the supervisor would uninstall it again)
Still decided to stick to Debian (with gui) and use VMWare workstation (as i was on W10 before)
However I did move some add-on’s to docker on the host ( and who knows, maybe some day i might abandon supervised )
Find your active interface:
sudo nmcli con show --active
The output shows something similar to:
NAME UUID TYPE DEVICE
Supervisor eno1 e874k675-44d4-31a4-8cf8-3b8cc5f3b7cb ethernet eno1
lo 1e5bf4e3-e5c6-40d4-a193-0ffaa1l4fd2b loopback lo
where
e874k675-44d4-31a4-8cf8-3b8cc5f3b7cb
is the active interface of my RPI4 used by Supervisor.
Now run the following command but use the UUID of your active interface:
sudo nmcli con mod "e874k675-44d4-31a4-8cf8-3b8cc5f3b7cb" ipv4.dns "8.8.8.8, 8.8.4.4"
With the above command you configure the RPI to resolve TLD’s using Google’s DNS servers (8.8.8.8 and 8.8.4.4). Of course you can change this to whatever valid DNS-servers of your choice.
Restart the NetworkManager service:
sudo systemctl restart NetworkManager
3 Likes
Hi everyone!
A clean supervised installation of HA on a new installed Debian 12 (bookworm) with LXDE. No other applications were installed. The installation was done accordingly to this guide.
First of all, the host with HA in unreachable.
The second issue:
journalctl -f shows that installation is stucked at “Get “https://ghcr.io/v2/””
Here is the log:
Apr 07 12:58:25 debian-ha systemd-resolved[4322]: Using degraded feature set TCP instead of UDP for DNS server 1.1.1.1.
Apr 07 12:58:28 debian-ha systemd-resolved[4322]: Using degraded feature set UDP instead of TCP for DNS server 8.8.8.8.
Apr 07 12:58:31 debian-ha systemd-resolved[4322]: Using degraded feature set TCP instead of UDP for DNS server 8.8.8.8.
Apr 07 12:58:34 debian-ha systemd-resolved[4322]: Using degraded feature set UDP instead of TCP for DNS server 1.0.0.1.
Apr 07 12:58:40 debian-ha dockerd[2219]: time="2024-04-07T12:58:40.570032578+03:00" level=warning msg="Error getting v2 registry: Get \"https://ghcr.io/v2/\": dial tcp: lookup ghcr.io: no such host" spanID=752c9dc820d58d66 traceID=ddb6f20b8123eb80b3f73c77e4e1b7ce
Apr 07 12:58:40 debian-ha dockerd[2219]: time="2024-04-07T12:58:40.570210901+03:00" level=info msg="Attempting next endpoint for pull after error: Get \"https://ghcr.io/v2/\": dial tcp: lookup ghcr.io: no such host" spanID=752c9dc820d58d66 traceID=ddb6f20b8123eb80b3f73c77e4e1b7ce
Apr 07 12:58:40 debian-ha dockerd[2219]: time="2024-04-07T12:58:40.712409403+03:00" level=error msg="Handler for POST /v1.45/images/create returned error: Get \"https://ghcr.io/v2/\": dial tcp: lookup ghcr.io: no such host" spanID=752c9dc820d58d66 traceID=ddb6f20b8123eb80b3f73c77e4e1b7ce
Apr 07 12:58:40 debian-ha hassio_supervisor[2219]: 2024-04-07 12:58:40.714 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/amd64-hassio-cli:2024.03.1: 500 Server Error for http+docker://localhost/v1.45/images/create?tag=2024.03.1&fromImage=ghcr.io%2Fhome-assistant%2Famd64-hassio-cli&platform=linux%2Famd64: Internal Server Error ("Get "https://ghcr.io/v2/": dial tcp: lookup ghcr.io: no such host")
Apr 07 12:58:40 debian-ha hassio_supervisor[2219]: 2024-04-07 12:58:40.715 WARNING (MainThread) [supervisor.plugins.cli] Error on install cli plugin. Retrying in 30sec
Apr 07 12:59:10 debian-ha hassio_supervisor[2219]: 2024-04-07 12:59:10.746 INFO (MainThread) [supervisor.docker.interface] Downloading docker image ghcr.io/home-assistant/amd64-hassio-cli with tag 2024.03.1.
Please give me any suggestions on this error.
Thank you in advance
DNS issues also?
Thank you for your comment.
It’s kinda network issue, I think
root@debian-ha:~# ha resolution info
Error response from daemon: No such container: hassio_cli
I think because the HA is not fully installed
In my opinion, DNS errors are better solved by:
edit /etc/systemd/resolved.conf, add DNS addresses (for example: DNS=8.8.8.8 1.1.1.1) and systemctl restart systemd-resolved.
I had to edit it twice - once when installing the necessary packages and twice after installing HA itself.
A much better idea than editing /etc/resolv.conf which gets overwritten.
Right before and at the docker installation you will most likely run into the “Temporary failure in name resolution” message, what most call DNS issues.
This is due to the previous apt command having installed, configured and started the network-manager which is now replacing systemd-resolved.
The correct way to solve the issue is Not to poke around the resolve.conf file nor resolvectl nor restart systemd-resolved.
If you did reboot your system first.
Instead run the NetworkManaget tool:
# nmcli d
which will return something like:
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet connected Supervisor enp4s0
lo loopback connected (externally) lo
docker0 bridge unmanaged --
hassio bridge unmanaged --
veth3ed17d5 ethernet unmanaged --
veth3ff491e ethernet unmanaged --
Now look for the connection name and run:
# nmcli conn modify "Supervisor enp4s0" ipv4.dns 1.1.1.1
# systemctl restart NetworkManager
I hope this saves someone the time I wasted figuring this out. 
1 Like
Just for the record, I’ve been running this installation as instructed for more than 3 years now. No major issues to report other than some recent issues with network connectivity. I’m running it out of an old laptop. Everything works with Apple Home too. Brilliant.
Cheers!
2 Likes
Hi,
on dns config: just my 2cents, hopefully it can help someone:
I also experienced the dns troubles.
My set-up: a fresh minimal install of debian 12 (no gui/desktop).
Typically I set a static ip via /etc/network/interfaces.
However as soon I installed the dependencies for HA (especially network-manager and systemd-resolved), I got in trouble with DNS.
Configuring dns via network-manager seemed:
a) not to work for some reason (i.e. apt could not resolve the repos but nslookup worked ok)
b) config on network via 2 locations/tools: dns via network-manager and static ip in /etc/network/interfaces
I also noticed that as long /etc/network/interfaces referenced my eth device, network-manager set the device as unmanaged and could not manage it (although it would create a connection).
Much google-ing and reading of posts (also in this thread) I came to following solution:
- mv /etc/network/interfaces /etc/network/interface.save (so that network-manager could manage the device)
- ensure systemd-networkd is not enabled (SystemdNetworkd - Debian Wiki)
- configure the network fully through network-manager
(e.g. NetworkConfiguration - Debian Wiki)
br,
Ruben
1 Like
Some additional information for those who are struggling with DNS issues:
I had to enable NetWorkmanager to manage my wired network first, by changing
managed=false
to
managed=true
in /etc/NetworkManager/NetworkManager.conf.
After that, do a
nmcli con show --active
which gives you something like:
NAME UUID TYPE DEVICE
Ifupdown (enp1s0) <someuid> ethernet enp1s0
lo <anotheruid> loopback lo
and then do a
nmcli con mod "<someuid>" ipv4.dns <myDNSIP>
and finally
service NetworkManager restart
After that DNS issues should be resolved and you can continue installing docker.
2 Likes
Same for me in Debian 12 Supervised install. Nothing restored the DNS not even disabling IPv6 in grub.
This worked for me:
Uncomment (or append) the line precedence ::ffff:0:0/96 100 in /etc/gai.conf
And them a reboot.
Did not work for me. Not even disabling ipv6 in grub.
Additionly I uncommented the line precedence ::ffff:0:0/96 100 in /etc/gai.conf to priortize ipv4 and rebooted.
That brought back the DNS.
After some reading and compiling several solutions here is what worked for me (HA Docker Supervised on Debian 12 - fresh Debian minimal install with no GUI in Virtualbox). I was able to recreate all the steps several times with success:
-
Log in as root with
sudo -i -
Install dependencies
apt install apparmor jq wget curl udisks2 libglib2.0-bin network-manager dbus lsb-release systemd-journal-remote systemd-resolved -y
- Don’t edit /etc/resolv.conf (I have learned it’s not persistent). Edit /etc/systemd/resolved.conf instead (it’s not so persistant either but it survives first reboot at least).
nano /etc/systemd/resolved.conf
- uncomment DNS to DNS=8.8.8.8 (probably whatever DNS server you prefer.
- I added my router’s IP 192.168.2.1 as FallbackDNS (uncomment it as well and add your router’s IP).
- uncomment ad change DNSStubListener=no
- save the file
!!! OUTSIDE VIRTUALBOX
- run dhclient enp1s0 (your ethernet instance that you get with ip a) - see if this resolves the connection
- you may probably need to install realtek-firmware from USB drive mounted in system
- Check your ethernet bridged connection
nmcli d
Probably your ethernet is unmanaged (in my case enp0s3). Edit /etc/NetworkManager/NetworkManager.conf file
nano /etc/NetworkManager/NetworkManager.conf
and change
[ifupdown]
managed=false
to
[ifupdown]
managed=true
as per https://linuxconfig.org/unmanaged-network-solution-on-debian-linux although it seemed that NetworkManager wasn’t installed on my Debian.
-
Reboot (rebooting through ssh creates an error and the VM closes down and needs to be restarted; rebooting twice in some cases may be necessary).
-
Log in again as root
sudo -i
- Execute commands one at a time:
curl -fsSL get.docker.com | sh
wget https://github.com/home-assistant/os-agent/releases/download/1.6.0/os-agent_1.6.0_linux_x86_64.deb
dpkg -i os-agent_1.6.0_linux_x86_64.deb
- Change folder to [root]/tmp and download installer
cd /tmp
wget https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb
and then run the installation
apt install ./homeassistant-supervised.deb
I got no errors with these steps and Home Assistant should be onboarding. But if you get an error that HA couldn’t start (it happend me twice) just restart Docker containter
sudo docker restart homeassistant
and wait a while.
Hope it works for you as well. Or maybe I was just lucky.