Unable to complete update - Beta FTL 5.9 issues

General beta
1

I noticed that FTL wasn't updated, so I ran update and it seems to be unable to update FTL properly. I've also noticed the "load" icon on the Pi-hole dashboard has been red more lately.

In fairness, I gave my Pi and Pi-hole a bunch of new things to do all within the past few days: I switched (for the first time) to use Pi-hole as the DHCP server (was having issues with my Orbi and AT&T modem), and switched to the beta.

The funny thing is, everything seems to be working properly, for the most part—I'm not getting the sporadic DNS errors I was getting before, but because I foolishly made so many changes all at once, I'm not sure if it's because of the beta, or because I set the Pi-hole to be the DHCP server (I suspect it's the latter, though).

Anyway, updated Raspbian and still couldn't properly update Pi-hole, so it's not crucial, but in the spirit of beta testing, see the link to my logs below. Hope this helps someone, and if anyone wants to me to test any solutions, just let me know. Cheers.

https://tricorder.pi-hole.net/eh448arqid

2

Did you make any changes to the network interfaces? There's a wlan0 interface that is listed but it doesn't seem to have an IP address.

Edit: Actually, you have some database image issues:

   [2021-07-22 01:00:49.447 609/T613] SQLite3 message: database corruption at line 94739 of [5c9a6c0687] (11)
   [2021-07-22 01:00:49.447 609/T613] SQLite3 message: statement aborts at 10: [DELETE FROM queries WHERE timestamp <= 1595375945] database disk image is malformed (11)
   [2021-07-22 01:00:49.713 609/T613] ERROR: SQL query "DELETE FROM queries WHERE timestamp <= 1595375945" failed: database disk image is malformed
   [2021-07-22 01:00:49.713 609/T613] delete_old_queries_in_DB(): Deleting queries due to age of entries failed!
   [2021-07-22 01:00:49.716 609/T613] SQLite3 message: API call with invalid database connection pointer (21)
   [2021-07-22 01:00:49.716 609/T613] SQLite3 message: misuse at line 126166 of [5c9a6c0687] (21)
   [2021-07-22 01:00:49.716 609/T613] ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: bad parameter or other API misuse
   [2021-07-22 01:00:49.716 609/T613] SQLite3 message: API call with invalid database connection pointer (21)
   [2021-07-22 01:00:49.716 609/T613] SQLite3 message: misuse at line 166280 of [5c9a6c0687] (21)
   [2021-07-22 01:00:49.716 609/T613] Error while trying to close database: bad parameter or other API misuse
   [2021-07-22 01:00:49.716 609/T613] ERROR: Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
   [2021-07-22 01:00:49.716 609/T613] SQLite3 message: API call with invalid database connection pointer (21)
   [2021-07-22 01:00:49.716 609/T613] SQLite3 message: misuse at line 166280 of [5c9a6c0687] (21)
   [2021-07-22 01:00:49.717 609/T613] Error while trying to close database: bad parameter or other API misuse
   [2021-07-22 01:01:01.828 609/T615] SQLite3 message: database is locked in "SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;" (5)
   [2021-07-22 01:01:01.829 609/T615] getNameFromIP("192.168.2.23") - SQL error prepare: database is locked
   [2021-07-22 01:01:07.095 609/T615] SQLite3 message: database is locked in "SELECT name FROM network_addresses WHERE name IS NOT NULL AND ip = ?;" (5)
   [2021-07-22 01:01:07.096 609/T615] getNameFromIP("192.168.2.99") - SQL error prepare: database is locked
   [2021-07-22 02:01:49.605 609/T613] SQLite3 message: database corruption at line 94739 of [5c9a6c0687] (11)
   [2021-07-22 02:01:49.606 609/T613] SQLite3 message: statement aborts at 10: [DELETE FROM queries WHERE timestamp <= 1595379605] database disk image is malformed (11)
   [2021-07-22 02:01:51.856 609/T613] ERROR: SQL query "DELETE FROM queries WHERE timestamp <= 1595379605" failed: database disk image is malformed
   [2021-07-22 02:01:51.856 609/T613] delete_old_queries_in_DB(): Deleting queries due to age of entries failed!
   [2021-07-22 02:01:51.860 609/T613] SQLite3 message: API call with invalid database connection pointer (21)
   [2021-07-22 02:01:51.861 609/T613] SQLite3 message: misuse at line 126166 of [5c9a6c0687] (21)
   [2021-07-22 02:01:51.861 609/T613] ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: bad parameter or other API misuse
   [2021-07-22 02:01:51.861 609/T613] SQLite3 message: API call with invalid database connection pointer (21)
   [2021-07-22 02:01:51.861 609/T613] SQLite3 message: misuse at line 166280 of [5c9a6c0687] (21)
   [2021-07-22 02:01:51.861 609/T613] Error while trying to close database: bad parameter or other API misuse
   [2021-07-22 02:01:51.861 609/T613] ERROR: Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
   [2021-07-22 02:01:51.862 609/T613] SQLite3 message: API call with invalid database connection pointer (21)
   [2021-07-22 02:01:51.862 609/T613] SQLite3 message: misuse at line 166280 of [5c9a6c0687] (21)
   [2021-07-22 02:01:51.862 609/T613] Error while trying to close database: bad parameter or other API misuse
   [2021-07-22 02:40:30.731 609M] Resizing "FTL-dns-cache" from 356352 to (22528 * 16) == 360448 (/dev/shm: 7.6MB used, 484.6MB total, FTL uses 7.6MB)
   [2021-07-22 02:40:46.554 609M] Resizing "FTL-domains" from 135168 to (8704 * 16) == 139264 (/dev/shm: 7.6MB used, 484.6MB total, FTL uses 7.6MB)

You can try the new database repair options that are included in the beta.

If anyone can post a link to the instructions, go ahead. I can't seem to find them. It's the sqlite3 repair.

3

I think this is it:

THIS IS COMPLETELY EXPIERIMENTAL, NO WARRANTY:

Stop FTL.

sudo systemctl stop pihole-FTL

Copy the existing pihole-FTL.db for backup.

sudo cp /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.db.orig

See if we can use FTL 's recovery:

sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.db .recover | sudo sqlite3 /etc/pihole/pihole-FTL.db.recovered

If that completes then move the recovered database to be used

sudo mv /etc/pihole/pihole-FTL.db.recovered /etc/pihole/pihole-FTL.db

Restart FTL

sudo systemctl start pihole-FTL
2 Likes
4

Sorry to have to ask, but what could I have done to mess with my network interfaces? I did have to edit the dhcpcd.conf (or something?) file to change the up address on the Pi because of the aforementioned router/modem issues (I spent many hours setting up IP pass through and cascading), but otherwise I don’t think I changed anything on the Pi.

Also, I can do a fresh install of Pi-hole—is that the database that seems problematic? Or is this something with my Raspbian install itself?

Thanks! And also, how embarrassing . . . I feel like I came in to ask about a broken finger, and it turns out my whole arm was broken. :grinning_face_with_smiling_eyes:

5

Lastly, your IPv6 is not working correctly.

*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] bunny.myfuncards.com is 0.0.0.0 on lo (127.0.0.1)
[✓] bunny.myfuncards.com is 0.0.0.0 on eth0 (192.168.2.83)
[✗] Failed to resolve bunny.myfuncards.com on wlan0 ()
[✓] doubleclick.com is 142.250.141.139 via a remote, public DNS server (8.8.8.8)

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] centralparkdenversaloon.com is :: on lo (::1)
[✓] centralparkdenversaloon.com is :: on eth0 (fe80::654d:a142:4b1b:5adf)
[✗] Failed to resolve centralparkdenversaloon.com on wlan0 ()
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
1 Like
6

Yeah, I turned IPv6 off in my router/modem wherever I could, when I was trying to diagnose the DNS issue I mentioned (that, now, seems to be resolved).

I’ll turn it back on, considering it didn’t seem to be the problem anyway.

7

(Also, again, thanks for the really thorough diagnosis / guidance!)

1 Like
8

Yeah, that would do it. That's where Raspbian configures IP addressing for it's network stack.

You can nuke the database completely if you want, you lose the history but it's a quick reset to see if that fixes things. There are some errors in the web error log but they look like they are unrelated and are probably from the beta.

If you want to nuke the database then:

Stop FTL.

sudo systemctl stop pihole-FTL

Move the database to a new name, you can delete it completely if you want later.

sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.db.orig

Restart FTL.

sudo systemctl start pihole-FTL
1 Like
9

OK, I first tried to nuke the database (nuclear option first, right?), and ran the debugger again and this is what I got:

https://tricorder.pi-hole.net/mf3efthjps

Looks like there were still database issues, and WLAN issues, and IPv6 issues (even though I had turned them back on in the modem/router).

Sooooo, I messed around with a bunch of IPv6 settings in my router and modem (because I'm doing a passthrough / cascaded router setup, I'm actually not sure how to set IPv6 since the passthrough IPv4 information is different from IPv6), and managed to completely kill my internet and then somehow resurrect it, and I ran an IPv6 test and it seems to work.

As for the WLAN issues, I just disabled it on my Pi, since I don't use it.

I still have the X-Header issue, but that seems to be a non-issue if everything else works (which I believe it does), and I think after doing the SQLITE repair, and then nuking it again, it seems to have resolved nearly all the database issues (except for one "file renamed while open" problem with gravity.db). FTL is up-to-date, so at least the initial problem I had has been resolved. THANK YOU!

But since the proverbial can of worms has been open, and since no good deed goes unpunished, now I have more questions for you. :slight_smile: What I'm left with now are the IPv6 issues. I tried editing setupVars.conf and adding in the IPv6 addresses I can find in my router now that it's turned back on and auto-configuring from the modem, but it didn't seem to work.

This is what I get from running pihole -d:

Pv6 address(es) bound to the eth0 interface:
   2600:1700:c0b0:5c60::48 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
   2600:1700:c0b0:5c60:4465:b195:5401:f97a does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
   2600:1700:c0b0:5c6f:ecce:75cf:289c:73c6 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
   fe80::654d:a142:4b1b:5adf does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

Here's the most recent debug log. Any ideas about the IPv6 issue, or any other problems I've got? I'm happy to do a full restart/complete reinstall of Pi-hole; the whitelists aren't really necessary, and I'm basically just using https://dbl.oisd.nl/ as my adlist, so easy to recreate from scratch.

https://tricorder.pi-hole.net/g3w9752zbu

12

Your first debug log already contained no new database issues, the old ones at the head of pihole-FTL.log where already a few hours old when you uploaded the log.

Don't worry too much about the

<addr> does not match the IP found in /etc/pihole/setupVars.conf

messages, this match is not necessary for the next version as FTL has learned to always find the correct address itself. I'll remove this misleading bit from the debugger.

However, both

[i] Default IPv6 gateway: fe80::<removed for privacy>
   * Pinging fe80::<removed for privacy>...
[✗] Gateway did not respond. (https://discourse.pi-hole.net/t/why-is-a-default-gateway-important-for-pi-hole/3546)

and also

[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)`

seem to suggest your Pi-hole does not have a working IPv6 connection to the Internet, despite

Final note: I don't think there are any issues left that could be fixed by reinstalling Pi-hole. The IPv6 issue is surely a system-wide issue. Have you tried pulling the Ethernet plug ans/or restarting the system to force it renewing its address after you did the router changes?