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.

Hi, thanks for the good suggestions for improvements. I agree on the git ls-remote problem, as well as on the concerns regarding network issues during installation. But triggered by the suggestion for the updatecheck timers, I currently tend to go into the opposite direction and remove any network calls to fetch remote version/hash.

I don't see a real use-case for these calls. It's not possible to update via pihole update and the package is managed via AUR/pacman. So the information, that there is a new upstream release doesn't add any real value for the user, as you cannot do much with this information.

Therefore I currently tend to have no update checks neither during install/upgrade hooks nor periodic at all. But happy to change this, if there is a use-case I'm currently missing.

Hi, I ran into a small issue while testing the current Pi-hole packages on a systemd-only Arch setup and thought it might be worth mentioning here.

updatecheck.sh: get_remote_hash() runs git ls-remote in the caller's current working directory. When the script is run as the pihole user from a directory containing a .git repository that pihole cannot read, Git repository discovery fails before the remote query with e.g. fatal: error reading '/home/user/.git'.

Using git -C / ls-remote ... avoids local repository discovery and makes the remote version check independent of the caller's working directory.

There is also a related scheduling issue on systemd-only Arch installations. Upstream Pi-hole normally runs pihole updatechecker daily and at boot through its cron configuration, but a system without a cron daemon has no periodic version refresh. FTL does not appear to provide an internal scheduler for these shell scripts, and pihole -v normally only reads the cached /etc/pihole/versions file.

Since the Arch package already uses systemd timers for recurring Pi-hole maintenance, I think it would make sense to add a native pi-hole-updatecheck.service and pi-hole-updatecheck.timer, for example running once daily with Persistent=true. This would also allow the network-dependent update check to be removed from package upgrade hooks, keeping GitHub access outside the pacman transaction while still maintaining regular version checks on systemd-only installations.

• Proposed updatecheck.sh patch
• Proposed systemd service
• Proposed systemd timer

I also noticed that pi-hole-core.install currently invokes updatecheck.sh from both post_install() and post_upgrade(). Since the checker performs network requests to GitHub, I think these calls could be removed along with adding the systemd timer described above. This would give the version checker a single, systemd-native scheduling mechanism and keep network-dependent version checks outside pacman transactions.

The timer could be shipped disabled in accordance with normal Arch systemd packaging behavior, with users enabling pi-hole-updatecheck.timer when they want automatic version checks.

dang, overlooked the logrotate change. Should be fixed and @bschnei sry, yes, one shouldn't do the updates when in a hurry. But now it's better to keep on increasing and only reset on the next version update.

There was a change to the location of the logrotate file. It was moved from /etc/pihole/logrotate to /etc/logrotate.d/pihole (https://github.com/pi-hole/pi-hole/commit/88b47a280ab6ee40449dce7f8536971a507530ff). Accordingly, the PKGBUILD should be updated to fix the error messages that occur during the nightly logtruncate run.

fabi: don't forget to reset pkgrel to -1 on pkgver increases :)

Good points, thanks. Looks like the setupVars.conf is not in use at all anymore, so probably best to also remove mimic_setupVars.conf.sh and remove it from the .install file. Furthermore, it probably makes sense to backup the pihole.toml file. I'll adjust the PKGBUILD accordingly.

fabi: thanks for adopting this! FYI the .install file attempts to grep etc/pihole/setupVars.conf but that file no longer exists in v6. The backup() array also includes etc/pihole/adlists.list which is also no longer used in v6. Neither of these issues causes the install to fail but warnings appear that could confuse users.

@fabi Thank you! Works with pi-hole-ftl-bin Result: Core v6.4.1 · FTL v6.6 · Web UI v6.5

Any objections to include the patch directly in the aur? I do have the 6.3.1 version of the patch in the cache and could add it updating to 6.4.1.

Furthermore I would update the CORE_VERSION in the patch from a fixed string to

pacman -Q pi-hole-core | awk '{print $2}' | cut -d- -f1

so it's hopefully not necessary to change the patch with each new version.