Pi-Hole gravity update fails

That would the allow to detail my previous reply:

And as you state you've changed your host's /etc/resolv.conf, that would suggest you didn't stop, remove and restart your Pi-hole container at that time for the changes to be picked up by your container.

I didn't want this to go this way, but how do you know what I did, only I know what I did
I have a script to stop,remove,create,stop,copy extra file config file for lighttpd,start the container
I ran that script, which also caused a reboot for some reason, might have been watchdog
that script also runs at reboot by crontab

I will be honest back the first time I did not restart, but after adding --dns I did

that line quotes there I edited in the post to shown what I would be like after a restart
I didn't want to cause downtime, just to update the copied from host section that is not really being used, well not at that time as "nameserver 127.0.0.1" was making it go though pi-hole

end of story now, I have resolved the issue and will not be replying anymore as it makes the thread messy if other people need to find the solution

Like I said I don't want to have to come to this, but I am annoyed that details were missed a few times

Details that you did not provide and my crystal ball never works right.

Okay, we'll see ya in a bit when it breaks again. :wink:

at that time, this was probole true

I hate when people doubt me, its impossible for it to break again

That was aimed to @Bucking_Horn not you @DanSchaper but anyway

"my crystal ball never works right."
Other forums/discourse have told me I have a "god like ability", this didn't come into affect here

anyway its 10:53 my rest time before bed, without this, I will be thinking about pi-hole all night

I will not be reading any more posts, I probably will, unless it gets locked, I can't stop myself, have to reply to everyone

You asked valid questions:

I tried to provide valid replies.

For doing so, I repeatedly asked you to share your host's /etc/resolv.conf.

Controlling resolv.conf can be finicky, as there's a multitude of tools used for it (resolvconf, openresolv, netplan, NetworkManager,...), probably at the same time, and they may allow other tools (dhclient, dhcpcd, unbound,...) to dynamically update resolv.conf.
I would have preferred to see its actual contents, which often contains a comment that would point to the tool currently in control, which may have allowed me to answer your first question.

But you never shared your host's resolv.conf, sharing two versions of your container's resolv.conf instead, and stating that you did change your host's resolv.conf, but still observed long resolution times when using 127.0.0.11, while DNS requests did not register in Pi-hole's UI at all.

The remaining explanation for those observations would be that the container was still using your old IP, unaware of your changes in /etc/resolv.conf, and that in turn...

All the way, I have been trying to answer your questions as best as I could, even when you did not always provide the details I've asked for, working with the information that you did provide.

I can understand that you dislike or disagree with my suggestion, but I don't see why you took offence in that suggestion, especially since you were fair enough to admit that may indeed have been the case at that time.

Thats not the case, it says NetworkManager but NetworkManager never updated the IP address since sharing was turned off

because all it says is

# Generated by NetworkManager
nameserver 192.168.1.252
nameserver 1.1.1.1

like I said though NetworkManager has not touched it

Sorry, that we not actually reading your full message "run from your Docker host system", I should have read that

That would have been the case, but by that point I was using 127.0.0.1

Sorry again, didn't see you wanted the host resolv.conf but that all I didn't provide

Sorry for what I said, If I had know you wanted the host config, I would have gave it to you
I am sorry for missing part of what you said
honestly reading back, I have no clue what annoyed me so much

I have had this issues from July 2024, and now I know what happened and actually it was user error with the host /etc/resolv.conf, the host system used to run NetworkManager sharing a wireless connection over ethernet, in July 2023 we changed ISP, then a few months later (as I thought) I ran a direct ethernet link to the router in May 2024 with powerline, so the NetworkManager link was no longer needed, resolv.conf never got updated, and I never thought to check

again I am Sorry and thank you for helping me get a solution and putting up with me missing information

Sorry this is long, sorry for my actions
I will make sure I read everything in the future

That's a strong indication that resolv.conf is under NetworkManager's control.

That doesn't mean that you cannot apply changes to that file manually, but you should expect them to be reverted to NM's information upon certain events, like connecting to a network, rebooting, renewing DHCP lease information or NM package updates.

I'm not sure what sharing you are referring to, but to prevent NM from touching resolv.conf, you'd usually change its dns option.

For the host (not inside the docker container), below is relevant again:

You can see whats configured in NetworkManager (for DNS) if run below:

sudo nmtui

Or:

nmcli -t -f name connection show --active | xargs -d '\n' -n 1 nmcli connection show

EDIT: What does below output on the host?

nmcli -t -f name connection show --active | xargs -d '\n' -n 1 nmcli -p -f ipv4.method,ipv4.dns connection show

Like I said not anymore not since July

If would be if I did not know the history of the configuration for Network Manager

How would that help you currently to determine where that nameserver in resolv.conf comes from?
And where is the output I requested?

I give up.

the first line says "generated by NetworkManager" but the setup that made the change in not being used anymore

Its solved and why would I send my full Network Configuration

that shows the main connection, but that uses DHCP and router DNS, the system does not seem to ever use this interface but instead uses macvlan interface that run the docker containers,, but the host also uses that over the Ethernet

I give up trying to explain my setup
I know Network Manager has not touched that file, as the DNS IP was incorrect, it would change it to 192.168.1.1(Router)

The fact is now its working

I will do a full host reboot, and show that /etc/resolv.conf stays unchanged
its still that same, everything still works
nothing was updating /etc/resolv.conf on the host