Thanks for the information.
@kanga_who, mind to take a look into this?
Whats going on here? I make a clrear installation on my raspberry pi 4 8gb debian 12
and when i reach that part:
curl -fsSL get.docker.com | sh
i get that errors:
xxx@xx:~$ ping google.com
ping: google.com: Temporary failure in name resolution
xxx@xxx:~$ ^C
xxx@xxx:~$ cat /etc/resolv.conf
domain localdomain
search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
xxx@xxx:~$ curl -fsSL get.docker.com | sh
curl: (6) Could not resolve host: get.docker.com
xxx@xxx:~$ ^C
xxx@xxx:~$
Its connected via Ethernet on network i also tried with sudo but nothing!
I fixed the above problem and now stuck on prepairing home assistant i get that log and go to loop:
23-09-06 23:59:21 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state running
23-09-06 23:59:21 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
23-09-07 00:01:20 WARNING (MainThread) [supervisor.misc.tasks] Watchdog miss API response from Home Assistant
23-09-07 00:03:20 ERROR (MainThread) [supervisor.misc.tasks] Watchdog found a problem with Home Assistant API!
23-09-07 00:03:20 ERROR (MainThread) [supervisor.misc.tasks] Home Assistant watchdog reanimation failed!
and on command promt i get this:
sudo dpkg -i homeassistant-supervised.deb
(Reading database ... 42254 files and directories currently installed.)
Preparing to unpack homeassistant-supervised.deb ...
[warn]
[warn] If you want more control over your own system, run
[warn] Home Assistant as a VM or run Home Assistant Core
[warn] via a Docker container.
[warn]
[warn] ModemManager service is enabled. This might cause issue when using serial devices.
Leaving 'diversion of /etc/NetworkManager/NetworkManager.conf to /etc/NetworkManager/NetworkManager.conf.real by homeassistant-supervised'
Leaving 'diversion of /etc/NetworkManager/system-connections/default to /etc/NetworkManager/system-connections/default.real by homeassistant-supervised'
Leaving 'diversion of /etc/docker/daemon.json to /etc/docker/daemon.json.real by homeassistant-supervised'
Leaving 'diversion of /etc/network/interfaces to /etc/network/interfaces.real by homeassistant-supervised'
Unpacking homeassistant-supervised (1.5.0) over (1.5.0) ...
Setting up homeassistant-supervised (1.5.0) ...
[info] Restarting NetworkManager
[info] Restarting docker service
PING checkonline.home-assistant.io (104.26.4.238) 56(84) bytes of data.
64 bytes from 104.26.4.238 (104.26.4.238): icmp_seq=1 ttl=59 time=16.4 ms
--- checkonline.home-assistant.io ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.371/16.371/16.371/0.000 ms
[info] Install supervisor startup scripts
[info] Install AppArmor scripts
[info] Start Home Assistant Supervised
[info] Installing the 'ha' cli
[info] Within a few minutes you will be able to reach Home Assistant at:
[info] http://homeassistant.local:8123 or using the IP address of your
[info] machine: http://192.168.1.15:8123
root@Raspi:/usr/local/src#
Is there any special reason why you want to switch from Home Assistant OS to HA Supervised?
Obviously not really.
This guide works well if one strictly sticks to the guide. You seem to have missed paragraph 1.5) and you have missed paragraph 1.6) for sure.
BTW, no need to append
sudo
to cli-commands if you are doing all as root user anyway. In contradiction to what this guide says.
It’s not exactly like that. To understand, it got fixed after 15 minutes. Up to 2.1, everything was done by the book, and the commands I’m entering are definitely remote via SSH. Everything broke after the command , the change ip and reboot fixes the problem with ping the only step that i skipped is the section 4.
Also the main reason I use home assistant supervised is that I want to have all the features of HA (add-ons) and also utilize the raspberry for other things and not “choke” it with only one function. This has been discussed many times, I think, and the reasons are obvious.
Suppose I install Home Assistant OS, can I run Unify Controller simultaneously? Can I set up a VPN Server? Can I have a docker environment for development that requires Debian?
:
apt install apparmor jq wget curl udisks2 libglib2.0-bin network-manager dbus lsb-release systemd-journal-remote systemd-resolved -y
Things messed up and this wasn’t working:
curl -fsSL get.docker.com | sh
The issue is that something is off when I do a ping, and this might be causing many of the problems I’m encountering. I restarted the raspberry again and, while I can normally access the Home Assistant, when I try SSH, I get:
:~$ ping google.com
ping: google.com: Temporary failure in name resolution
It’s as if every time it’s activated, the network manager breaks.
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group defaul t qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group defa ult qlen 1000
link/ether d8:3a:dd:33:4f:fa brd ff:ff:ff:ff:ff:ff
altname end0
inet 192.168.1.15/24 brd 192.168.1.255 scope global dynamic eth0
valid_lft 80826sec preferred_lft 80826sec
inet6 fe80::da3a:ddff:fe33:4ffa/64 scope link
valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qle n 1000
link/ether d8:3a:dd:33:4f:fb brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gr oup default
link/ether 02:42:0a:63:44:fa brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe63:44fa/64 scope link
valid_lft forever preferred_lft forever
5: hassio: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP gro up default
link/ether 02:42:0a:1f:44:a8 brd ff:ff:ff:ff:ff:ff
inet 172.30.32.1/23 brd 172.30.33.255 scope global hassio
valid_lft forever preferred_lft forever
inet6 fe80::42:aff:fe1f:44a8/64 scope link
valid_lft forever preferred_lft forever
7: veth621e7ed@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue mas ter hassio state UP group default
link/ether 52:36:27:a5:be:76 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::5036:27ff:fea5:be76/64 scope link
valid_lft forever preferred_lft forever
9: veth0cf35fa@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue mas ter docker0 state UP group default
link/ether 82:4b:1f:c4:8b:3e brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::804b:1fff:fec4:8b3e/64 scope link
valid_lft forever preferred_lft forever
11: vethda82419@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 86:72:ed:73:4b:20 brd ff:ff:ff:ff:ff:ff link-netnsid 1
inet6 fe80::8472:edff:fe73:4b20/64 scope link
valid_lft forever preferred_lft forever
13: veth3f3b8b9@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 06:3e:82:4b:09:63 brd ff:ff:ff:ff:ff:ff link-netnsid 2
inet6 fe80::43e:82ff:fe4b:963/64 scope link
valid_lft forever preferred_lft forever
15: vetha5f8663@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 8e:77:76:9a:92:44 brd ff:ff:ff:ff:ff:ff link-netnsid 3
inet6 fe80::8c77:76ff:fe9a:9244/64 scope link
valid_lft forever preferred_lft forever
17: veth34b5d9c@if16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 6a:4e:d7:7f:ad:1e brd ff:ff:ff:ff:ff:ff link-netnsid 4
inet6 fe80::684e:d7ff:fe7f:ad1e/64 scope link
valid_lft forever preferred_lft forever
19: veth3cc95b9@if18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether e2:64:7f:d6:dd:cc brd ff:ff:ff:ff:ff:ff link-netnsid 5
inet6 fe80::e064:7fff:fed6:ddcc/64 scope link
valid_lft forever preferred_lft forever
21: vethc1531e3@if20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue m aster hassio state UP group default
link/ether 3a:d9:6a:5d:c6:ee brd ff:ff:ff:ff:ff:ff link-netnsid 6
inet6 fe80::38d9:6aff:fe5d:c6ee/64 scope link
valid_lft forever preferred_lft forever
Nope.
With HA Supervised installed but not following ADR0012 / ADR0014 be prepared to run into that “Unhealthy” and “Unsupported” states with your HA installation.
Maybe. But not as that unpriviledged user you are supposed to go from here but you continued directly as the root user as your edited/non-edited log snippets show.
Anyway, you can try the following.
Firstly disable ModemManager from starting after reboots:
sudo systemctl status ModemManager
If modem manager is running stop and disable it:
sudo systemctl stop ModemManager
sudo systemctl disable ModemManager
Now make sure the latest NetworkManager is installed:
sudo dpkg -s network-manager
The output should show:
Package: network-manager
Status: install ok installed
If not, install NetworkManager:
sudo apt install network-manager
Now reboot the host:
sudo systemctl reboot
To prevent /etc/resolv.conf
is getting overwritten with every reboot do the following:
Using the CLI edit /etc/NetworkManager/NetworkManager.conf
Search for the [main] section in this file. It should look something like this:
[main]
dns=default
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file
Now change dns=default to dns=none just after the [main] tag like this:
[main]
dns=none
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file
Save the file and restart NetworkManager.service:
sudo systemctl restart NetworkManager.service
Edit /etc/resolv.conf
and add the DNS-server(s) of your choice.
If you haven’t already screwed-up your installation you should be able to continue with:
sudo -i
curl -fsSL get.docker.com | sh
which should finally bring you to the next level.
Finally everything works again!
i made all steps correctly without problem one notice:
after reboot i run again the:
:~$ ping google.com
ping: google.com: Temporary failure in name resolution
Something overwrites settings after reboot , what can cause that problem?
Look one post up:
Check your /etc/resolv.conf after a reboot. If the definition for the DNS servers you configured in there before are overwritten to something else you have not followed the steps correctly.
/etc/NetworkManager/NetworkManager.conf
sudo nano /etc/NetworkManager/NetworkManager.conf
GNU nano 7.2 /etc/NetworkManager/NetworkManager.conf
[main]
dns=none
plugins=keyfile
autoconnect-retries-default=0
rc-manager=file
[keyfile]
unmanaged-devices=type:bridge;type:tun;driver:veth
[logging]
backend=journal
[connection]
connection.mdns=2
connection.llmnr=2
[connectivity]
uri=http://checkonline.home-assistant.io/online.txt
[device]
wifi.scan-rand-mac-address=no
/etc/resolv.conf
domain localdomain
search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
Maybe is something else because as you can see the setup didnt change after reboot but ping doesnt get response.
Is NetworkManager running?
sudo systemctl status NetworkManager.service
If NetworkManager is not running start it with:
sudo systemctl start NetworkManager.service
followed by:
sudo systemctl enable NetworkManager.service
What is
sudo ha dns info
telling?
systemctl status NetworkManager.service
@Raspi:~$ sudo systemctl status NetworkManager.service
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; prese>
Active: active (running) since Thu 2023-09-07 09:59:35 UTC; 58min ago
Docs: man:NetworkManager(8)
Main PID: 475 (NetworkManager)
Tasks: 3 (limit: 9245)
Memory: 20.3M
CGroup: /system.slice/NetworkManager.service
└─475 /usr/sbin/NetworkManager --no-daemon
Sep 07 09:59:58 Raspi NetworkManager[475]: <info> [1694080798.9479] device (ve>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2853] manager: (>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2926] manager: (>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.8592] device (ve>
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8029] manager: (>
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8214] manager: (>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.3166] device (ve>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5572] manager: (>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5651] manager: (>
Sep 07 10:07:32 Raspi NetworkManager[475]: <info> [1694081252.0976] device (ve>
lines 1-20/20 (END)
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-09-07 09:59:35 UTC; 58min ago
Docs: man:NetworkManager(8)
Main PID: 475 (NetworkManager)
Tasks: 3 (limit: 9245)
Memory: 20.3M
CGroup: /system.slice/NetworkManager.service
└─475 /usr/sbin/NetworkManager --no-daemon
Sep 07 09:59:58 Raspi NetworkManager[475]: <info> [1694080798.9479] device (vethcc2f29d): ca>
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2853] manager: (veth838a45a): >
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2926] manager: (vethceefdc0): >
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.8592] device (vethceefdc0): ca>
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8029] manager: (vetha7e8c55): >
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8214] manager: (veth9fb97f0): >
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.3166] device (veth9fb97f0): ca>
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5572] manager: (vethb65a8e8): >
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5651] manager: (veth607a23d): >
Sep 07 10:07:32 Raspi NetworkManager[475]: <info> [1694081252.0976] device (veth607a23d): ca>
● NetworkManager.service - Network Manager
Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; preset: enabled)
Active: active (running) since Thu 2023-09-07 09:59:35 UTC; 58min ago
Docs: man:NetworkManager(8)
Main PID: 475 (NetworkManager)
Tasks: 3 (limit: 9245)
Memory: 20.3M
CGroup: /system.slice/NetworkManager.service
└─475 /usr/sbin/NetworkManager --no-daemon
Sep 07 09:59:58 Raspi NetworkManager[475]: <info> [1694080798.9479] device (vethcc2f29d): carrier: link connected
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2853] manager: (veth838a45a): new Veth device (/org/freedesktop/NetworkManager/Devices/17)
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.2926] manager: (vethceefdc0): new Veth device (/org/freedesktop/NetworkManager/Devices/18)
Sep 07 09:59:59 Raspi NetworkManager[475]: <info> [1694080799.8592] device (vethceefdc0): carrier: link connected
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8029] manager: (vetha7e8c55): new Veth device (/org/freedesktop/NetworkManager/Devices/19)
Sep 07 10:07:30 Raspi NetworkManager[475]: <info> [1694081250.8214] manager: (veth9fb97f0): new Veth device (/org/freedesktop/NetworkManager/Devices/20)
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.3166] device (veth9fb97f0): carrier: link connected
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5572] manager: (vethb65a8e8): new Veth device (/org/freedesktop/NetworkManager/Devices/21)
Sep 07 10:07:31 Raspi NetworkManager[475]: <info> [1694081251.5651] manager: (veth607a23d): new Veth device (/org/freedesktop/NetworkManager/Devices/22)
Sep 07 10:07:32 Raspi NetworkManager[475]: <info> [1694081252.0976] device (veth607a23d): carrier: link connected
ha dns info
Raspi:~$ sudo ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals: []
mdns: true
servers: []
update_available: false
version: 2023.06.2
version_latest: 2023.06.2
@Raspi:~$
It is not picking up the nameservers you have configured inside /etc/resolv.conf
.
Change:
domain localdomain
search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
into:
#domain localdomain
#search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
and try again.
Weird, i change to
#domain localdomain
#search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
i check that is saved, i run sudo systemctl restart NetworkManager.service
and after that run dns info that is locals: ,
i try to make reboot and i notice that the file is again
domain localdomain
search localdomain.
nameserver 8.8.8.8
nameserver 8.8.4.4
Try again by setting the nameserver address within /etc/resolv.conf to your router’s (DHCP server) ip address:
domain localdomain
search localdomain.
nameserver your-routers-ip
Fixed! But with a litle different way, we reduce the problem only on the dns that doesnt pick unfortunantelly after reboot again i had the same entries, so i searched a litle and i found a different way to set permament dns
I run
nmcli con show --active
To see active interfaces,
i see my eth0 with id ,etc and i set with that command the dns
nmcli con mod "501ba88f-a6be-4d68-bfd6-84696ba74aab" ipv4.dns "8.8.8.8, 8.8.4.4"
after reboot everything works (ping)
i recheck the file resolv.conf and i have this:
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
search .
also on dns info:
sudo ha dns info
fallback: true
host: 172.30.32.3
llmnr: true
locals:
- dns://8.8.8.8
- dns://8.8.4.4
mdns: true
servers: []
update_available: false
version: 2023.06.2
version_latest: 2023.06.2
i think now im ok , and with reboot nothing changes!! Thank you very very much for your help!
Excellent
I installed Homeassistant supervised on Debain 12 running on Raspberrypi 4 8gb.
I followed each step very carefully.
Initially the system was showing “supported” but after two or three restarts now it’s showing “unsupported”.
Kindly guide how to fix this.
Scroll up in this thread. The CGroup issue has been discussed more than once and is easy to fix.
Also note about HA’s information on CGroup Version.
Hi,
I installed Homeassistant supervised on Debain 12 running on Raspberrypi 4 8gb.
I followed each step very carefully.
Initially the system was showing “supported” but after two or three restarts now it’s showing “unsupported”.
Will the above command fix the “Unsupported” issue on Debian 12?
Why not just give it a try?