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! 
Overly complicated work around to be fair.
I usually just Nano systemd.unified_cgroup_hierarchy=0 back into the cmdline file. Then reboot.
Just seems like that should be unnecessary though.
Agreed, to each his own - actually, that reminds me - I’ve made alot of changes time to do a full backup of the whole disk image
…and additionally not without certain risks.
To make this even more simple just type the following command through CLI:
sudo sed -i.bak 's/$/ systemd.unified_cgroup_hierarchy=0/' /boot/firmware/cmdline.txt
and reboot.
The above command will take care of writing a backup of the original file (/boot/firmware/cmdline.txt.bak) to be prepared just in case something goes wrong.
Sure that workaround also works.
The work around doesn’t address my question though.
Is there a way to stop a work around being required…
sounds like no at this point.
Seemingly No at this point. This did never happen with Debian 11 (at least here). I am still investigating the latter on a dev RPI4 with HA Supervised on Debian 12.
It occurred in deb 11 also for me. I was hoping deb 12 would cease the behaviour.
Was also hoping deb 12 might have made the systemd ver2 to cgroupfs ver1 change unnecessary.
Oh well. It’s only a minor inconvenience in the scheme of things.