Package Details: pi-hole-ftl 6.1-1

Git Clone URL: https://aur.archlinux.org/pi-hole-ftl.git (read-only, click to copy)
Package Base: pi-hole-ftl
Description: The Pi-hole FTL engine
Upstream URL: https://github.com/pi-hole/FTL
Licenses: EUPL-1.2
Conflicts: dnsmasq
Provides: dnsmasq
Submitter: max.bra
Maintainer: max.bra (graysky)
Last Packager: max.bra
Votes: 59
Popularity: 1.26
First Submitted: 2017-05-07 15:23 (UTC)
Last Updated: 2025-03-30 17:00 (UTC)

Required by (65)

Sources (5)

Pinned Comments

max.bra commented on 2018-02-09 16:46 (UTC) (edited on 2019-10-18 23:13 (UTC) by max.bra)

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.

Latest Comments

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 46 Next › Last »

max.bra commented on 2020-03-25 09:08 (UTC)

@deemon i don't want to be rude but: what are you saying? do you see any dnsmasq movable file in any pi-hole package? dnamasq is "embedded" into piholeFTL. there is nothing we can do about it.

deemon commented on 2020-03-25 00:40 (UTC)

What? It's supposedly already providing dnsmasq (there's a fork of dnsmasq included in the piholeftl code they say), but not well enough. Can you make the pi-hole-FTL in-built dnsmasq more like actual dnsmasq and act like it?

If need be add some links to pi-hole dnsmasq binaries or something that programs like libvirtd can find them?

max.bra commented on 2020-03-24 21:59 (UTC)

i don't think so, regardless of whether or not to provide dnsmasq, it will always be in conflict

deemon commented on 2020-03-24 21:50 (UTC)

My problem with this is that supposedly:

Conflicts:  dnsmasq
Provides:   dnsmasq

Yet, it DOES NOT provide dnsmasq for other programs that depend on it...

like virt-manager 's libvirtd

[deemon@Zen ~]$ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
     Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; disabled; vendor preset: disabled)
     Active: active (running) since Tue 2020-03-24 23:29:49 EET; 2min 37s ago
TriggeredBy: ● libvirtd-ro.socket
             ● libvirtd-admin.socket
             ● libvirtd.socket
       Docs: man:libvirtd(8)
             https://libvirt.org
   Main PID: 20101 (libvirtd)
      Tasks: 17 (limit: 32768)
     Memory: 93.7M
     CGroup: /system.slice/libvirtd.service
             └─20101 /usr/bin/libvirtd

märts 24 23:29:49 Zen systemd[1]: Started Virtualization daemon.
märts 24 23:29:49 Zen libvirtd[20101]: libvirt version: 5.10.0
märts 24 23:29:49 Zen libvirtd[20101]: hostname: Zen
märts 24 23:29:49 Zen libvirtd[20101]: Libvirt doesn't support VirtualBox API version 6001004
märts 24 23:29:49 Zen libvirtd[20101]: Cannot check dnsmasq binary /usr/bin/dnsmasq: No such file or directory

Can it be fixed somehow?

Treyarch commented on 2020-03-02 05:28 (UTC)

I might be a cabbage here, but I seem to be getting An unknown error occured while loading the data.

When going to the Network tab or any long term data, I have tried a few of the fixes here already and it looks lime they're already working, I can't seem to find the log that is telling me what's going on either :(

max.bra commented on 2020-02-29 17:50 (UTC) (edited on 2020-02-29 17:55 (UTC) by max.bra)

@pepper_chico yes, you are right. updating... Done! Thanks for reporting.

pepper_chico commented on 2020-02-29 16:08 (UTC) (edited on 2020-02-29 16:29 (UTC) by pepper_chico)

Hi folks, previously I've commented I keep getting these log rotation errors on journal logs (reversed messages):

systemd[1]: pi-hole-logtruncate.service: Succeeded.
systemd[1]: Failed to start Rotate log files.
systemd[1]: logrotate.service: Failed with result 'exit-code'.
systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
logrotate[2047]: error: error renaming temp state file /var/lib/logrotate.status.tmp
pihole[2057]: error: Ignoring /etc/pihole/logrotate because the file owner is wrong (should be root or user with uid 0).
systemd[1]: shadow.service: Succeeded.

/etc/pihole/logrotate is owned by pihole:pihole on boot, even if I change owner to root:root, on next boot it's back to pihole:pihole. The thing is, this error shows up because pi-hole-logtruncate.service is executed as root? When running sudo logrotate -d /etc/pihole/logrotate (leaving pihole:pihole owner as is), I get the same error, but if I run without sudo it doesn't show this error (the reverse is also true, running with sudo is fine if owner is root:root). So I'm thinking whether these other services need to set User=pihole Group=pihole like pihole-FTL.service? Or permissions for files need to be fixed for these other services to execute correctly (I'm counting pi-hole-logtruncate.service and pi-hole-gravity.service).

For the moment I'm adding another permission fixup to pihole-FTL.service: ExecStartPre=/bin/chown root:root /etc/pihole/logrotate.

max.bra commented on 2020-02-26 11:02 (UTC)

oops

MarcinWieczorek commented on 2020-02-26 11:01 (UTC)

Yeah thanks, but tar.gz is missing.

max.bra commented on 2020-02-26 10:55 (UTC)

aah ok i see. updated w/o version bump.

« First ‹ Previous 1 .. 20 21 22 23 24 25 26 27 28 29 30 .. 46 Next › Last »