Search results

Other than errors indicating that network is unreachable when trying to connect to upstream DNS (1.0.0.1) there is nothing useful there. I assume you have listeningMode set to LOCAL, you might try setting it to ALL (and make sure you don't open port 53 in your router), maybe when the reconnect...

I used to host Pi-hole on Pi Zero powered by router's USB port using Ethernet adapter. Over the years my setup switched from using adapter to just using USB Ethernet gadget mode to directly connect to the router without any extra accessory. Then Pi-hole dropped lighttpd dependency and made...

That's all that comes to my mind: pihole debug # upload when asked netstat -tulnp | pihole tricorder cat /etc/dnsmasq.conf | pihole tricorder You could probably use wan-event script to just reload Pi-hole when reconnect happens if we can't get this fixed any other way

There is a WAN disconnect at Dec 9 16:49:55 in the log, I dunno why would it break pi-hole. Maybe newer firmware does something I am not aware of. Perhaps there would be more insight in Pi-hole logs

Update released following upstream: 2025.11.27-1 https://pi-hole.net/blog/2025/11/27/pi-hole-ftl-v6-4-web-v6-4-and-core-v6-3-released/ Some memory optimizations are mentioned.

My bad, readlink -f will follow the symlink to the asuware.arm directory. I replaced the code with something simplier

Hmmm, I dunno why it doesn't work then. I assume you see "Mounted '/tmp/mnt/drivename/entware' on /tmp/mnt/drivename/asusware.arm" instead of "Mounted '/tmp/mnt/drivename/entware' on /tmp/opt" in the syslog? Maybe try rebooting the router if it is not a problem, unless you already did that earlier.

Did you update via jas update or fetched the script manually? I force-pushed to the repository later and maybe you have the outdated version. The earlier version did not remove the link, so the mount command still followed /tmp/opt to /tmp/mnt/drivename/asusware.arm and mounted over it instead.

The code at the beggining of the script should resolve /opt once, so $opt should become /tmp/opt, then code in mount_opt should delete /tmp/opt and make it a regular directory so mount --bind can work. I would like to avoid putting any mounts on the USB device itself as it could lead to some...

In the meantime I also pushed another change that now only resolves one level of the symlink and deletes it (/tmp/opt in your case) before mounting to make sure the mount is not created on the asusware directory but whatever /opt is pointing to. This change might be incompatible with the...

Pushed another change to the develop branch, let me know if it works.

What about df /opt 2> /dev/null | grep -Fv "/dev/root" | tail -n +2 ? I've renamed is_entware_mounted to is_opt_mounted to better reflect what that function is for, it now has two conditions and excludes /dev/root. If I resolve the symlinks they will lead me to asusware directory, which is not...

The workaround is utilizing something included in the firmware, you can't undo /opt=>/tmp/opt symlink as the filesystem is read-only, that's why bind-mount is required here. Is 'drivename' the actual label of your USB device? Does the real label contain any unusual characters? Try entware script...

This is really weird behavior, no idea why would mounting entware folder show up as asusware.arm What device? Is it newer or older model than mine? Does the Entware actually start? What is the output of: cat /proc/mounts df

This might happen if you unplug the stick after Entware script mounted /opt as Entware /tmp/mnt/drivename/asusware.arm is not Entware folder by the workaround / Asus apps, this is caused by Asus app scripts I am personally using both usb-mount-script and entware script and never seen this happen...

Also, if I remember correctly, ps only shows virtual allocations, not real usage. Only the MEM% is real usage, I think. Correct me if I'm wrong here. You might want to check memory usage percentage displayed in Settings->System.

Settings -> Privacy, set "Maximum number of days to keep queries in the database" to something low like 8 days and wait few hours.

That memory usage could be caused by the size of pihole-FTL.db, for comparison mine is around 65M and I keep only last 30 days of queries in it.

What are the sizes of gravity.db and pihole-FTL.db?

How long have you been running it? Maybe there is memory leak somewhere again. In FTL v6.3 dev version there was a memory leak that I reported and it got fixed. FTL periodically performs a maintenance of pihole.FTL.db database where it has to load it completely into the memory, if the database...