Arch Linux User Repository

ArchLinux Pi-hole is not officially supported by Pi-hole project. In case of bugs and malfunctions please DO NOT file a report upstream.

First of all check if the wiki (https://wiki.archlinux.org/index.php/Pi-hole) can help then ask here for assistance and tips.
When it will be excluded that the problem does not depend on ArchLinux we will file a bug upstream.

to update to pi-hole 6, please use pi-hole-core pi-hole-ftl and pi-hole-web packages.

@trainzkid @deemon
the 01-pihole.conf problems should be solved with latest releases.

pi-hole's archlinux distribution, in addition to being unsupported by the official team, is also voluntarily very different: it is without any debugging utility (the official team specifically requested, rightly, not to receive debug logs from a distribution they do not support), without any “automatic” recovery utility (this is archlinux), and is definitely more static in installation, upgrade, and removal.
It is normal, therefore, to expect that it is taken for granted (this is archlinux) that a merge between the various .pacnew and .pacsave should be done.
This does not detract from the fact that the backup during package installation of the 01-pihole.conf file was a bit overkill and inconvenient.
Let's see how it goes now, if things are better and less problematic, barring of course some possible oversight by the maintainers.

@graysky / @max.bra

Not sure if these are any help in the discussion about updating /etc/dnsmasq.d/01-pihole.conf from /etc/pihole/setupVars.conf via cli:

• Refreshing dnamasq from CLI?

• restartdns not updating dnsmasq configs

As someone whose DNS was suddenly unavailable following an update+reboot (maybe the 3rd or 4th time in a row?), I'd love some attention on this. The good news is the more times it happens, the quicker I'm able to find the problem.

That first article mentioned possibly using the -r/reconfigure flag with pihole for this issue, but those don't seem to work on my system. I expected the dnsmasq file to be updated on restart/reload of the service file, but that's not the case either.. very confusing.

@deemon - you have to manually diff the two files retaining the relevant settings, although I agree that the upstream comments regarding auto populated should be removed or we should regenerate it each time.

@max.bra - what do you think is the better course?

Pihole generally works. Without web interface, which is intended. However I have an issue, that it tries on update to overwrite (well, generate .pacnew) of /etc/dnsmasq.d/01-pihole.conf , and when applied as is, making the pihole fail (well, in status work, but in reality not resolve ANY queries). Because it deletes the lines for server=1.1.1.2 (your chosen upstream DNS) and interface=<your network interface name>. The update process does not take into account anything from /etc/pihole/setupVars.conf (where I have set up (also) PIHOLE_INTERFACE=<interface name> and PIHOLE_DNS_1=1.1.1.2) and should be used to autogenerate /etc/dnsmasq.d/01-pihole.conf file on installation AND UPDATE <= which it does not, and is my problem here.

/etc/dnsmasq.d/01-pihole.conf does say:

###############################################################################
#      FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE.      #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
#                                                                             #
#        IF YOU WISH TO CHANGE THE UPSTREAM SERVERS, CHANGE THEM IN:          #
#                      /etc/pihole/setupVars.conf                             #
#                                                                             #
#        ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE           #
#                    WITHIN /etc/dnsmasq.d/yourname.conf                      #
###############################################################################

This file automatic population does not work in current upgrade procedure.

OR the /etc/dnsmasq.d/01-pihole.conf should have more accurate instructions how to trigger this automatic population in the Arch/AUR version.

clean your aur helper cache

fix checksum: beeb08d8e7225100e37cc789a48f1bea64cd07111c880d3fb43a9cee7bb15fae arch-server-admin-5.21-1.patch

(sorry for multiple messages) of course, as a container, the kernel is different (5.15 proxmox debian based), but honestly don't think it could be relevant in this context. in my experience with pi-hole, the additional layer of variability inserted by a container can only make things worse and not better

... (forgot) with DHCP enabled via web app