One solution to prevent resolv.conf gets overwritten with every restart of the host I have described here. Not a dirty hack but the change of a simple configuration variable within NetworkManager.conf.
1 Like
I’ll try that one Tamsy, thanks.
Do you also have a solution for preventing NM making a new connection profile on every boot? I have a whole bunch of them and they keep growing in number. Seached Google on this and many people have this problem, but no working solutions.
I never heard nor experienced such a behavior. Maybe this happens every time you manually set the DNS server through resolv.conf? I would delete all profiles except the main profile, configure NetworkManager.conf as described (don’t forget to add a DNS server to resolv.conf after having restarted NM) and watch whether this behavior is still happening.
It is indeed a strange problem, you can look it up yourself on Google should you be interested.
Deleting the profiles is tricky when doing so from a remote location, if you delete the active one you loose your connection.
Before your suggestion about DNS=none I changed resolv.conf’s attributes with chattr +i /etc/resolv.conf, making it read only
Well, that’s indeed a dirty hack 
Will do it later after I’m back home.
What do you see when executing from the CLI:
sudo nmcli connection show
root@pi344:~# nmcli connection show
NAME UUID TYPE DEVICE
Supervisor eth0 ec28412f-2106-48e2-9178-eff102a08002 ethernet eth0
Supervisor eth0 a599dac3-9b87-4cbd-a135-0d834153f6ed ethernet –
Supervisor eth0 2c40c00f-8c9a-4582-9015-894b2b58c8c2 ethernet –
Supervisor eth0 4f20ae74-c026-41a6-aa11-bea76c3c90fa ethernet –
Supervisor eth0 8a70959d-c364-4fb2-ad77-58119cc94a60 ethernet –
Supervisor eth0 d6e11048-c04f-426f-8333-26f3744a116c ethernet –
Supervisor eth0 c813899a-41fb-486f-924c-e045dedf6ef3 ethernet –
Supervisor eth0 f5226b2b-7610-4b69-bff3-b2b3494c4cae ethernet –
Supervisor eth0 5ec304b5-5f2c-42f5-aafc-ec22560f6ac5 ethernet –
Supervisor eth0 1e450762-1921-43b8-9f22-f5b99a33a475 ethernet –
Supervisor eth0 f0ecf4ad-5727-43d0-87e3-d8b4999d5344 ethernet –
Supervisor eth0 6ed24a1d-8ebf-45a9-8944-051bd54b99ce ethernet –
Supervisor eth0 84d670a7-3715-4a8d-9add-88a5691823ae ethernet –
Supervisor eth0 03b2521b-0316-470f-9743-55a8c57265ac ethernet –
Supervisor eth0 21455580-de3a-4b52-9069-ef797baff276 ethernet –
Supervisor eth0 964f0b82-dcab-4313-a804-9e0c2bd1cead ethernet –
Supervisor eth0 8717ecc3-3c31-47f2-8195-e5fe2461c098 ethernet –
Supervisor eth0 85233ad5-f8b6-4e6f-b8f8-ad65442bbc6d ethernet –
Supervisor eth0 7d89c902-b4a9-45d8-8266-ce5f30fb5b7e ethernet –
Supervisor eth0 874b8d5b-1af4-4662-ba08-c060939b62ea ethernet –
Supervisor eth0 21e18ec6-1fae-4ffd-8087-069e67c26bb4 ethernet –
Supervisor eth0 fd18e2b6-0882-411c-97b4-d935fbb00380 ethernet –
Supervisor eth0 1253a9c7-c90d-41bd-b3f7-535af4048738 ethernet –
First make sure to not to touch the active connection. Check by executing:
sudo nmcli connection show --active
Note the UUID of the active connection. Don’t tamper with this one!
While we could delete all the non-active connections by using only one command and some awk magic lets do this one by one starting from the bottom working ourselves up:
sudo nmcli connection delete uuid 1253a9c7-c90d-41bd-b3f7-535af4048738
sudo nmcli connection delete uuid fd18e2b6-0882-411c-97b4-d935fbb00380
all the way up to:
sudo nmcli connection delete uuid a599dac3-9b87-4cbd-a135-0d834153f6ed
Restart NetworkManager:
sudo systemctl restart NetworkManager.service
Now check the connection(s) again:
sudo nmcli connection show
You shoulds only see:
NAME UUID TYPE DEVICE
Supervisor eth0 ec28412f-2106-48e2-9178-eff102a08002 ethernet eth0
Finally configure nm to not to overwrite /etc/resolv.conf with every reboot as described earlier today.
1 Like
@Tamsy & @Patrick010 FYI - being a noob to some extent to Linux and Python (I have HA Supervised running on a RPI4 w/8Gig of Ram and not using any microsd card but a 1tb samsung T7 SSD) - I am not upgrading yet, but earlier when I did sudo apt update and sudo apt upgrade I did have some container related upgrades which caused by HA Supervised to be unhealthy (cgroup version issue). So I reran “curl -fsSL get.docker.com | sh” and homeassistant-supervised.deb but those did not resolve the issue. So “for fun” I did try the in-place upgrade to Debian 12 anyway (which is probably a bad starting point from trying same) but that did cause me to have both two of the “Supervisor eth0” entries above, and DNS not resolving either (able to ping 1.1.1.1 but not google.com for example). So, I just restored from a backup and will just do the full - from scratch - Debian 12 install later. Tamsy you may remember that following your and kanga-who’s instructions I did have that DNS hiccup which I resolved so I am digging to find out what I did before to resolve that issue. When I do the reinstall from scratch for Debian 12, I will very thoroughly document any resolution I do for the DNS issue (if I have that iossue again) - so you can decide where or if to include that with your installation instructions -
I have done this countless times, but the entries keep coming back. No idea what’s causing it
You made this clear before. What I am wondering about is does it still happen after you made the change to NetworkManager.conf (and restarted nm)? 
This should have been enough to resolve the issue:
1 Like
Thanks for your reply, happy with Debian 11 for now I’ll do the in-place upgrade when required
So do I on production devices 
I dont understand either. And yes, I did a full restart, just to be sure 
awesome write-up! thank you!!
1 Like
An alternative to generating keys, is to add the password to the sysconf.txt file then edit the etc/ssh/sshd_config file on the other partition of the SD card/USB device (done easily in Linux by mounting it) and change:
PermitRootLogin yes
You are refering to what posting in this topic?
I really would refrain from putting that root password as cleartext on the device itself!
Furthermore setting PermitRootLogin to yes is not a good idea either.
Isn’t sysconf.txt cleared after first run?
But besides that, if you have console access then you might as well passwd root from the cli