Installing Home Assistant Supervised using Debian 12

I want to inform you that this advice is wrong. If the machine is on the home network behind the router, then you need to specify the router address, in my case 192.168.1.1. If it still swears and reports a Temporary failure in name resolution, then simply restart the machine and re-launch apt install ./homeassistant-supervised.deb, then we will be offered to run dpkg ....-a and the installation will be fine

in resolv.conf, you need to specify the address of your router, you may have different

cat /etc/resolv.conf
nameserver 192.168.1.1

If we specify nameserver 1.1.1.1, we will get this error

ping download.docker.com
ping: download.docker.com: Temporary failure in name resolution

If we specify nameserver 192.168.1.1, we will get the answers

ping download.docker.com
PING d2h67oheeuigaw.cloudfront.net (13.32.121.29) 56(84) bytes of data.
64 bytes from server-13-32-121-29.fra60.r.cloudfront.net (13.32.121.29): icmp_seq=1 ttl=246 time=41.5 ms
64 bytes from server-13-32-121-29.fra60.r.cloudfront.net (13.32.121.29): icmp_seq=2 ttl=246 time=41.6 ms
64 bytes from server-13-32-121-29.fra60.r.cloudfront.net (13.32.121.29): icmp_seq=3 ttl=246 time=41.7 ms
64 bytes from server-13-32-121-29.fra60.r.cloudfront.net (13.32.121.29): icmp_seq=4 ttl=246 time=43.3 ms
64 bytes from server-13-32-121-29.fra60.r.cloudfront.net (13.32.121.29): icmp_seq=5 ttl=246 time=43.6 ms
64 bytes from server-13-32-121-29.fra60.r.cloudfront.net (13.32.121.29): icmp_seq=6 ttl=246 time=43.0 ms

Aehm, no - we won’t get this error. You do.

> server 1.1.1.1
Standardserver:  one.one.one.one
Address:  1.1.1.1

> download.docker.com
Server:  one.one.one.one
Address:  1.1.1.1

Nicht autorisierende Antwort:
Name:    d2h67oheeuigaw.cloudfront.net
Addresses:  2600:9000:2240:ae00:3:db06:4200:93a1
          2600:9000:236e:7a00:3:db06:4200:93a1
          2600:9000:236e:f000:3:db06:4200:93a1
          2600:9000:236e:bc00:3:db06:4200:93a1
          2600:9000:236e:9200:3:db06:4200:93a1
          2600:9000:236e:7c00:3:db06:4200:93a1
          2600:9000:236e:c400:3:db06:4200:93a1
          2600:9000:236e:0:3:db06:4200:93a1
          13.32.121.78
          13.32.121.35
          13.32.121.29
          13.32.121.111
Aliases:  download.docker.com

with Google DNS

> server 8.8.8.8
Standardserver:  dns.google
Address:  8.8.8.8

> download.docker.com
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
Name:    d2h67oheeuigaw.cloudfront.net
Addresses:  2600:9000:2453:3800:3:db06:4200:93a1
          2600:9000:2453:8e00:3:db06:4200:93a1
          2600:9000:2453:e00:3:db06:4200:93a1
          2600:9000:2453:5c00:3:db06:4200:93a1
          2600:9000:2453:800:3:db06:4200:93a1
          2600:9000:2453:8000:3:db06:4200:93a1
          2600:9000:2453:cc00:3:db06:4200:93a1
          2600:9000:2453:a800:3:db06:4200:93a1
          18.155.145.38
          18.155.145.96
          18.155.145.73
          18.155.145.122
Aliases:  download.docker.com

No, it isn’t.

Nope. That advise is perfectly correct.

Check whether your router allows DNS passthrough on UDP port 53. Some cheap home routers/modems are blocking DNS requests to outside DNS servers on UDP port 53 from the LAN but force the users to exclusively use their build-in DNS server.

Also be aware of the fact that many ISP’s around the world are intercepting DNS requests through transparent proxies without the users ever realizing it (this is also called DNS Hijacking).
Unfortunately it is common practice for ISP’s to hijack and redirect DNS traffic to their local DNS servers. Whatever DNS servers you have configured with your devices inside the LAN, those traffic will silently get redirected to the ISP’s DNS servers (thus the name “Transparent Proxy”).

Back to your router/modem. Especially if this is a device provided by your ISP there is a big chance that your ISP is blocking all DNS traffic which is not coming from that specific router/modem.

There are sites on the internet like DNS Leak Test where you can check whether your ISP has implemented a transparent proxy to intercept your outbound DNS requests.

1 Like

Maybe I’m doing something wrong, but for some reason I’m getting this curl error for the second time: (6) Could not resolve host: get.docker.com. I installed a clean Debian 12 and re-installed Home Assistant. When I get to the curl -fsSL get.docker.com | sh step, the docker installation does not start, I get curl: (6) Could not resolve host: get.docker.com. I specify nameserver 1.1.1.1.1 according to your instructions and it still does not work to run curl -fsSL get.docker.com | sh.

If I specify nameserver 192.168.1.1 and do systemctl restart systemd-resolve.service, then download.docker.com pinged

I can run curl -ssl get.docker.com |sh after reboot and with nameserver 192.168.1.1, and after installing Home Assistant I can ping download.docker.com , if I specify in /etc/resolv.conf nameserver 1.1.1.1

You have a specific issue not related to the instructions, perhaps a regional issue or hardware.

The instructions work. They have been tested more times than I care to remember and used by hundreds if not thousands of users.

Just 7 posts up you might find the solution to the issue you are encountering.

Could you try installing a clean Debian 12 and go through all the steps?

sudo -i

apt update && sudo apt upgrade -y && sudo apt autoremove -y

apt --fix-broken install

apt install apparmor jq wget curl udisks2 libglib2.0-bin network-manager dbus lsb-release systemd-journal-remote systemd-resolved -y

curl -fsSL get.docker.com | sh

I have curl -fsSL get.docker.com | sh running if I reboot Debian 12 after installing the packages. I would like to understand if this is a personal problem or if I’m just doing it wrong. I do not reboot Debian 12 after installing packages. Could this be my mistake? After rebooting, if I specify nameserver 1.1.1.1.1, download.docker.com is pinged. It’s just that I didn’t encounter this problem on Debian 11, but now I have and it’s confusing me

apt install apparmor jq wget curl udisks2 libglib2.0-bin network-manager dbus lsb-release systemd-journal-remote systemd-resolved -y

Note about systemd-resolved which is expected by HA Supervised:

The new systemd-resolved package will not be installed automatically on upgrades. You need to install the new package manually. Note that until it has been installed, DNS resolution might no longer work since the service will not be present on the system.

Installing this package will automatically give systemd-resolved control over /etc/resolv.conf. If you don’t want this, follow this post to regain control over /etc/resolv.conf.

Follow the links I have posted just above your latest post and you should be good.

1 Like

This. :point_up:

I don’t need to try them again.

If you don’t understand all this you might want to consider to install Home Assistant OS rather than insisting on the Home Assistant Supervised installation method since the latter is considered advanced and should only be used if one is an expert in managing a Linux operating system, Docker and networking!

What’s even stranger is that when I install Debian 12 I get the error no privileged access

I read here about Privileged

The Supervisor needs to have privileged access to the docker runtime on your host to be able to do everything it needs to do.

I tried some solutions on the forum, but they didn’t work, so I turned to ChatGPT 3.5. ChatGPT3.5 recommended me to do the following and it worked

Add a user to the docker group

sudo usermod -aG docker root

Open daemon.json file

nano /etc/docker/daemon.json

and add the line “group”: “docker”.

The “group”: “docker” parameter in the Docker Daemon configuration file (/etc/docker/daemon.json) tells Docker Daemon to use the docker group to define users who can perform operations on Docker. When Docker Daemon is run with this setting, any user who is a member of the docker group has privileged access to Docker, allowing them to execute Docker commands without using sudo or administrator privileges.

    "log-driver": "journald",
    "storage-driver": "overlay2",
    "group": "docker",
    "ip6tables": true,
    "experimental": true,
    "log-opts": {
        "tag": "{{.Name}}"
    }
}

image

Rebooted the docker with the command

sudo systemctl restart docker

Huh?!? Where is this step written within the guide? :thinking:

1 Like

It’s not in the instructions, it’s just that after installing Home Assistant I got this message

English please, we don’t read Russian.

Edit. Thanks for correcting

If you aren’t going to follow the instructions, please do not continue to post in this thread.

Are you sure you want to add user “docker” to the “root”-group " ???

Seems you are wildy copy/pasting some commands you have found somewhere on the internet without a clue of what you are actually doing.

If you are unable to follow above guide (OP) strictly and by the book than do yourself (and this community) the favor and go for HA OS.

I just wanted to voice the problems I have encountered with Debian 12. Maybe I’m the only one and I’m just unlucky. My main machine with Home Assistant is running Debian 11 and there are no problems there, everything works fine. Before upgrading from Debian 11 to Debian 12 on my live machine, I decided to test this on a virtual machine and had problems. Later, after testing with Debian 12 I put Debian 11 on the virtual machine and the installation of Home Assistant went perfectly, no problems and also after installing Home Assistant in Home Assistant there is no privilege error.

But you haven’t even read the RELEASE NOTES for Debian 12, have you?

I wrote that I contacted ChatGPT and ChatGPT gave me that information and it worked. I don’t know how I can properly troubleshoot a privilege problem on Debian 12. If you know how to properly troubleshoot this problem, please let me know how to do so