I'm trying to get Pi-hole up and running on an Alpine LXC. Installed using this. My troubleshooting is telling me there's a problem with the gravity DB. I can't figure out how to fix it though. Below are a few indicators I'm seeing. Debug token at the end. Any help would be very much appreciated.
Clicking "Groups" in UI gives a popup with: { "error": { "key": "database_error", "message": "Could not read domains from database table", "hint": "Database not available", "took": "2.93......" } }
Adding a block list in UI gives an error "Database not available".
Renaming gravity.db and running pihole -g does nothing.
Output of pihole -r looks fine. Nothing changes.
Running pihole -up claims everything is up to date. pihole -v says otherwise: Core version is v6.1.1 (Latest: v6.4.3) Web version is v6.6 (Latest: v6.6) FTL version is v6.7 (Latest: v6.7)
Two different sets of errors in debug log that I can see:
2026-07-22 15:32:04.753 UTC [1275M] ERROR: Cannot parse TOML file:
2026-07-22 15:32:04.753 UTC [1275M] INFO: Config backup file /etc/pihole/config_backups/pihole.toml.1 not available (r): No such file or directory
2026-07-23 11:53:05.134 UTC [34135/T34191] ERROR: gravityDB_open(): Failed to prepare allowlist statement: SQL logic error
2026-07-23 11:53:05.134 UTC [34135/T34191] WARNING: gravityDB_count(3): Gravity database not available
2026-07-23 11:53:05.135 UTC [34135/T34191] ERROR: SQLite3: no such table: vw_allowlist in "SELECT id FROM vw_allowlist WHERE domain = ?1 AND group_id IN carray(?2);" (1)
I ran pihole -g -r recover but I have previously tried pihole -r.
I just tried the recreate command. UI has the same errors but the debug log shows it definitely did something to gravity (below). Still the same errors further down the log.
*** [ DIAGNOSING ]: Gravity Database
-rw-r----- 1 pihole pihole 5.1M Jul 23 16:34 /etc/pihole/gravity.db
*** [ DIAGNOSING ]: Info table
property value
version 19
gravity_restored false
updated 1784824486
gravity_count 89947
Last gravity run finished at: Thu Jul 23 16:34:46 UTC 2026
----- First 10 Gravity Domains -----
localhost.localdomain
ad-assets.futurecdn.net
ck.getcookiestxt.com
eu1.clevertap-prod.com
wizhumpgyros.com
coccyxwickimp.com
webmail-who-int.000webhostapp.com
010sec.com
01mspmd5yalky8.com
0byv9mgbn0.com
Maybe the issue is caused by some third party changes.
Also, this code was last updated more than one year ago (you installed core v6.1.1 - the current core version is v6.4.3).
Maybe there are some incompatibilities between the installed app (v6.1.1) and the current Pi-hole FTL and Web components.
I can't promise it will work because we couldn't find the exact issue, but I'm sure that using an outdated version (and mixing old and new components) won't help you.
I'm going to continue this thread rather than open a new one.
I uninstalled pihole that had previously been installed with the custom script. The official install script actually worked this time, I got the install wizard, everything looks good.
My problem now is that it just doesn't seem to be able to query the upstream DNS. Below are some tests I've run. I've cleared the DNS cache between each test, since it just gets the data it needs from the cache otherwise.
I've set the pihole to manage DHCP but that didn't have an effect.
It's the ISP router - Vodafone Gigabox. Those tests were me trying to rule out a loop and to check if the pihole was not working at all or just when it was receiving queries from the router. "dev machine DNS" is what my own laptop resolv.conf was showing, "router DNS" is what the router was set to.
So any idea why this is not working? Anything I can check?
So "dev machine DNS" means "DNS used by my device", correct?
In this case, why are you trying to use 192.168.1.1 (router) as DNS for your devices? Don't do that.
You should use Pi-hole IP as DNS server... and you already said it works when using it.
Your Pi-hole is the DHCP server.
Pi-hole is already advertising 192.168.1.15 as DNS server to all your devices.
The devices are correctly sending all DNS queries to Pi-hole and Pi-hole is answering them.
That's it. It is working.
Your router doesn't need to use Pi-hole. It can use any DNS server, including the ISP ones.
Ok here's where I'm at. Router is set to "auto". I don't know what that means. The other option is to give it an IP address. resolv.conf on this laptop is showing the IP of the pihole. If I load a website I can see the queries in the pihole UI. If I turn on the VPN this is overwritten to the VPN provider's DNS IPs. Turn off the VPN, it goes back to the pihole IP.
What exactly is editing the resolv.conf file? If I haven't told the router to use the pihole then how is resolv.conf showing the pihole? Do devices also receive a DNS IP when they get an IP from the DHCP server?
Thanks for the help on this. Looks like it's working. I don't have a very good understanding of how all this works (as you can probably tell), but I'm getting there!
Usually when a router DNS is set to Auto, it uses the DNS information provided by your ISP. That can be a DNS server run by the ISP, or they may be pushing out a public DNS like 8.8.8.8. And that's fine; usually that just tells the router where to look up queries and doesn't impact devices on your LAN unless you allow/configure it to do so.
resolv.conf is set by the operating system, and will usually state which specific thing is writing to it right there in the contents of the file. For example, on my Raspberry Pi running Trixie OS:
NetworkManager is a network setup utility in the Trixie OS. Older versions of R-Pi OS use different methods of writing to resolv.conf, but anything that is writing to it should be listed like shown above (e.g. 'Generated by NetworkManager'). This means if I manually edit resolv.conf, NetworkManager will overwrite it on next reboot.
This setting is independent of what my DHCP service offers for DNS addresses. My Pihole uses public DNS, all my LAN clients use Pihole at 192.168.3.200.
So if the router has it's own DNS set (whatever "auto" implies) and resolv.conf is using the pihole ("# Generated by NetworkManager") then which DNS address is prioritised? It all goes through the router anyway so is that in charge of forwarding the DNS queries?
resolv.conf should be your "source of truth" in this case as I understand it; whatever is in your resolv.conf is what the Raspberry Pi (not necessarily Pihole) uses for DNS. You can confirm this by going to a terminal prompt on your R-Pi and running a "dig google.com" or whatever target you like. In the output, you should see a line like below near the end:
That tells you that 9.9.9.9 is the server that answered the DNS query. But Pihole (running on the same device) on my setup has an upstream server of 127.0.0.1:53, which is the Unbound service.
Pihole (not the R-Pi's resolv.conf) is what my other client machines use to resolve DNS. So the path from a client is "client/Pihole/Unbound/root servers". But the path from the R-Pi, in the example above, is "R-Pi/9.9.9.9".
Hopefully that makes sense. The router DNS settings can only affect the Pihole if you tell Pihole to use your router for upstream DNS queries -- a normal setup for Pihole will use one or more of the predefined upstream DNS sources. The router DNS settings will only affect your Raspberry Pi if you tell your router to hand out its own address to LAN devices for DNS via DHCP settings, or you manually setup resolv.conf to point to your router.
As another example, my router is set to use a public DNS for its own lookups. But it has DHCP configured to hand out my Pihole's address to LAN clients. And the Raspberry Pi itself isn't affected because it's configured for a static/reserved IP and doesn't ask for DHCP information from upstream.
That explains a lot. Thanks to you both for your help with this. In my defence, setting up pihole was in large part intended as a learning exercise. The router is set to auto, the pihole is the DHCP server and everything on the network is using the pihole IP for DNS. Mission accomplished!
Same here; when I first setup Pihole lo those many years ago, it was first to learn the Raspberry Pi and some basic Linux and second to filter DNS. With the great help I've gotten here from other users and devs, plus what I've managed to piece together on my own, I've managed to pick up quite a bit more than I ever would have otherwise.
It's a great tool for learning, plus it does a really good job!
