pihole -up
has no effect. I get checking for update, told that updates are available, but then
[i] Update repo in /etc/.pihole...
: Could not update local repository. Contact support.
I have tried several times to upload my debug log, but when I do I get an error. At this point I think I am just trying to start over, but despite being an admin, it seems like I have no privileges, if I try to move or delete /etc/.pihole or /var/www/html/admin I am told permission denied.
At some point I might just erase the whole drive and start over, however everything on the raspberry should be up to date, I am running version 10 (buster), and fwiw, I am running pihole v4.1.1.1 because it's been years since I have been able to update or fix my problem. I will try just about anything.
Have you tried the following?
sudo rm -r /etc/.pihole
This isn't quite up to date. There are two newer OS versions out since this. Bullseye (11) and just released last week Bookworm (12).
Also an ancient version. We released V5 in May 2020, more than three years ago.
I would flash a fresh new OS (perhaps on a fresh SD card as well, since yours has some miles on it) and do a clean install of the current version of Pi-hole.
I took your advice, and just started over. I am now running a clean install of the latest Raspberry Pi OS. I ran curl -sSL https://install.pi-hole.net | bash and was told that my OS was not supported (it was reported as Raspbian 12), so I reran skipping OS check, and it seems to be working.
Maybe I need to open a new ticket, but I have a new issue. My load times are averaging 1.4 when the used to average 0.4 on my old install, so I know it can be better. My memory usage is only at 30%, but I am running a Raspberry Pi 1 build B if the issue is old hardware with new software.
Please elaborate. "Load times", and what software or window is showing these numbers? What are the units that go with these numbers?
I don't actually see units, so I'm not sure, but this from what's showing up in the top left of pi.hole/admin. I've got green circles for "active" and memory, but then red circle and an error in the tools letting me know that loads above 1 can cause bottleneck issues. It hasn't gone above 1.6, but it also hasn't dropped down below 1.2 on any single instance that I've tried watching.
You are referring to the "load average", which is displayed in the web Admin GUI and is taken directly from the OS.
Here's a little background reading:
It is not unusual for the CPU on a low spec Pi (or any Pi, for that matter) to be fully utilized for short periods.
When you install Pi-hole, that uses a lot of CPU. Same for running apt upgrade, rebuilding gravity, etc.
Unless the Pi is stuck on 1.4 load, you don't need to worry about this. CPU utilization changes over time.
Here is an example. This is a NanoPi NEO (mid spec SBC) running Armbian Bookworm.
Normally it sits on the shelf, doing its Pi-hole thing, with very little load:
nanopi-neo:~:# uptime
14:38:30 up 4 days, 23:38, 1 user, load average: 0.08, 0.02, 0.01
But, if I run a gravity update (and this Pi-hole only uses two lists, so there isn't a whole lot of work to update gravity) you see the load jump up as expected.
nanopi-neo:~:# pihole -g
[i] Neutrino emissions detected...
[✓] Pulling blocklist source list into range
[✓] Preparing new gravity database
[✓] Creating new gravity databases
[i] Using libz compression
[i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
[✓] Status: Retrieval successful
[✓] Parsed 144648 exact domains and 0 ABP-style domains (ignored 1 non-domain entries)
Sample of non-domain entries:
- "0.0.0.0"
[i] List has been updated
[i] Target: https://www.github.developerdan.com/hosts/lists/ads-and-tracking-extended.txt
[✓] Status: Retrieval successful
[✓] Parsed 429230 exact domains and 0 ABP-style domains (ignored 0 non-domain entries)
[i] List has been updated
[✓] Building tree
[✓] Swapping databases
[✓] The old database remains available
[i] Number of gravity domains: 573878 (565421 unique domains)
[i] Number of exact blacklisted domains: 4
[i] Number of regex blacklist filters: 27
[i] Number of exact whitelisted domains: 36
[i] Number of regex whitelist filters: 0
[✓] Flushing DNS cache
[✓] Cleaning up stray matter
[✓] FTL is listening on port 53
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
nanopi-neo:~:# uptime
14:39:04 up 4 days, 23:39, 1 user, load average: 0.36, 0.09, 0.03
Then, fairly quickly over time, the load is reduced again and quickly goes back to the steady state value I normally see.
nanopi-neo:~:# uptime
14:39:18 up 4 days, 23:39, 1 user, load average: 0.28, 0.09, 0.03
nanopi-neo:~:# uptime
14:40:48 up 4 days, 23:41, 1 user, load average: 0.06, 0.06, 0.02
Not exactly a light read, but useful. Thanks.
It is stuck at 1.4. I haven't seen it go lower.
10:27:09 up 39 min, 2 users, load average: 1.52, 1.60, 1.54
I don't know why there are two users, but I made a debug report just in case. At this point I have made a fresh install of Raspberry Pi OS, installed Pi-hole, and nothing else. I haven't added any white list, block list (not that either of those would have an effect on load, I just wanted to point out how I've done nothing else), installed other apps, made any modifications, etc.
Take a look at the output of this command from the Pi terminal, which will show you the resources being used by all processes.
htop
Sort by CPU and you will see the highest CPU users.
It seems the biggest CPU user is /usr/lib/xorg/Xorg followed by /usr/sbin/lightdm. /usr/bin/dbus-daemon is also pretty consistently using CPU. So it seems like the desktop is the problem.
I ran sudo raspi-config and changed boot to auto login to text console instead of desktop. It is now much better.
12:34:16 up 7 min, 2 users, load average: 0.43, 1.15, 0.81
Still not sure why there are two users, but rerunning htop shows pi-hole as the biggest CPU user now, usually around 1%, often less.
What led you install a version of Raspbian with a desktop environment, and not the headless Lite version?
Mostly a "what if I come across a problem I can't solve through SSH?" I wasn't sure what that problem would be, and if I did I imagine starting over would be easier. Basically, I don't have a great answer, and if I do it again I expect I will go the headless lite route, but I don't feel like reimaging now if it won't cause any further issues.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.