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? 
I am new to Linuxā¦ so always a little scared while trying commands at terminal ā¦
Just entered the command nowā¦ Itās showing supported now.
Thanks 
Is there a way to stop the cgroup version reverting to systemd/cgroup ver 2 all the time?
This is possibly some quirk with my setup.
Whenever I update docker or linux security updates (eg. linux-image-6.1.0-12-arm64 or linux-image-arm64).
My cgroup reverts to systemd and ver 2 from cgroupfs an ver 1.
It also seems
systemd.unified_cgroup_hierarchy=0
is being removed from
/boot/firmware/cmdline.txt
Is this just me or does it happen to everyone?
Is there a solution to avoid having to re add this line after most linux updates?
I just stopped playing those games (trying to fix the cgroup version problem manually as quite a while ago that didnāt fix my issue) and just run the below commands one at a time - will only take you a few minutes - (you wonāt lose anything):
sudo -i
apt update && sudo apt upgrade -y && sudo apt autoremove -y
apt --fix-broken install
cd /usr/local/src
Check the above thread - or this URL to see if the OS-Agent I use below is the latest one first - (currently 1.6.0) -
At this point I check on the contents of the directory and clean the old .deb files out if I am getting newer ones, then (make sure you are still in there a āsudo -iā first):
wget https://github.com/home-assistant/os-agent/releases/download/1.6.0/os-agent_1.6.0_linux_aarch64.deb
dpkg -i os-agent_1.6.0_linux_aarch64.deb
wget https://github.com/home-assistant/supervised-installer/releases/latest/download/homeassistant-supervised.deb
dpkg -i homeassistant-supervised.deb
Best to reboot at this point -
This happens from time to time, sometimes after you update the underlying OSā¦ with a variation of:
sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y
So, the above steps allow you to ensure you have the latest and greatest and yet, not have to worry about cgroup version issues (and you do not lose your configuration either) - but always back everything up! 