I just updated my RPI running pihole with the latest pihole version 6.4.2. I was on version 6.0 before. I tried to use pihole -up to do this. I am running on an RPI 4b and it is installed bare metal. Bookworm is the os being used.
Your debug log shows that Pi-hole was inoperational at the time of debug log creation:
*** [ DIAGNOSING ]: Pi-hole-FTL full status
× pihole-FTL.service - Pi-hole FTL
Loaded: loaded (/etc/systemd/system/pihole-FTL.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Fri 2026-06-05 20:05:05 EDT; 3min 24s ago
Duration: 263ms
Process: 25065 ExecStartPre=/opt/pihole/pihole-FTL-prestart.sh (code=exited, status=0/SUCCESS)
Process: 25078 ExecStart=/usr/bin/pihole-FTL -f (code=exited, status=1/FAILURE)
Process: 25079 ExecStopPost=/opt/pihole/pihole-FTL-poststop.sh (code=exited, status=0/SUCCESS)
Main PID: 25078 (code=exited, status=1/FAILURE)
CPU: 404ms
Jun 05 20:05:05 shutyourpihole systemd[1]: pihole-FTL.service: Scheduled restart job, restart counter is at 5.
Jun 05 20:05:05 shutyourpihole systemd[1]: Stopped pihole-FTL.service - Pi-hole FTL.
Jun 05 20:05:05 shutyourpihole systemd[1]: pihole-FTL.service: Start request repeated too quickly.
Jun 05 20:05:05 shutyourpihole systemd[1]: pihole-FTL.service: Failed with result 'exit-code'.
Jun 05 20:05:05 shutyourpihole systemd[1]: Failed to start pihole-FTL.service - Pi-hole FTL.
In addition, your debug log shows critical errors related to Pi-hole's shared memory storage (shm):
-----tail of FTL.log------
(…)
2026-06-05 20:04:54.356 EDT [24654M] WARNING: Could not fallocate() in realloc_shm() (/app/src/shmem.c:866): No space left on device
2026-06-05 20:04:54.356 EDT [24654M] CRIT: realloc_shm(): Failed to resize "/FTL-24654-queries" (10) to 309237940224: No space left on device (28)
2026-06-05 20:04:59.981 EDT [25078M] INFO: ########## FTL started on shutyourpihole! ##########
(…)
2026-06-05 20:05:00.087 EDT [25078M] ERROR: SQLite3: database corruption at line 78666 of [737ae4a347] (11)
2026-06-05 20:05:00.087 EDT [25078M] ERROR: SQLite3: statement aborts at 6: database disk image is malformed; [SELECT COUNT(*) FROM disk.query_storage WHERE timestamp BETWEEN ? AND ?] (11)
2026-06-05 20:05:00.087 EDT [25078M] ERROR: db_query_int_from_until(SELECT COUNT(*) FROM disk.query_storage WHERE timestamp BETWEEN ? AND ?) - SQL error step (11): database disk image is malformed
2026-06-05 20:05:00.087 EDT [25078M] WARNING: Could not fallocate() in realloc_shm() (/app/src/shmem.c:866): No space left on device
2026-06-05 20:05:00.087 EDT [25078M] CRIT: realloc_shm(): Failed to resize "/FTL-25078-queries" (10) to 309237940224: No space left on device (28)
There's also a series of reoccurring SQL errors during Pi-hole's regular database clean-ups:
-rw-r----- 1 pihole pihole 619K Jun 5 20:05 /var/log/pihole/FTL.log
-----head of FTL.log------
2026-06-05 00:01:00.091 EDT [890/T975] ERROR: SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2026-06-05 00:01:00.092 EDT [890/T975] ERROR: ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2026-06-05 00:01:00.092 EDT [890/T975] ERROR: Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
(…)
2026-06-05 00:09:00.102 EDT [890/T975] ERROR: SQLite3: statement aborts at 1: [BEGIN TRANSACTION IMMEDIATE] cannot start a transaction within a transaction (1)
2026-06-05 00:09:00.103 EDT [890/T975] ERROR: ERROR: SQL query "BEGIN TRANSACTION IMMEDIATE" failed: SQL logic error (SQLITE_ERROR)
2026-06-05 00:09:00.103 EDT [890/T975] ERROR: Storing devices in network table ("BEGIN TRANSACTION IMMEDIATE") failed
2026-06-05 00:10:00.049 EDT [890/T975] ERROR: SQLite3: statement aborts at 52: [DELETE FROM query_storage WHERE id IN (SELECT id FROM query_storage WHERE timestamp <= 1772770200 LIMIT (SELECT COUNT(*)/100 FROM query_storage));] database disk image is malformed (11)
2026-06-05 00:10:00.049 EDT [890/T975] ERROR: ERROR: SQL query "DELETE FROM query_storage WHERE id IN (SELECT id FROM query_storage WHERE timestamp <= 1772770200 LIMIT (SELECT COUNT(*)/100 FROM query_storage));" failed: database disk image is malformed (SQLITE_CORRUPT)
2026-06-05 00:10:00.050 EDT [890/T975] WARNING: Database /etc/pihole/pihole-FTL.db is damaged and cannot be used.
I'm guessing here, but it could be that your database is corrupted in a way that would trigger Pi-hole to load an excessive amount of stored queries into shared memory, exhausting your system's shm pool, ultimately preventing it to start.
You could try to move your corrupted query database out of the way and restart Pi-hole's service:
sudo systemctl stop pihole-FTL.service
sudo mv /etc/pihole/pihole-FTL.db /etc/pihole/pihole-FTL.corrupted.db
sudo systemctl start pihole-FTL.service
If an integrity check on the corrupted db fails, queries from your corrupted database are lost:
sudo pihole-FTL sqlite3 /etc/pihole/pihole-FTL.corrupted.db "PRAGMA integrity_check"
In that case, you could just delete pihole-FTL.corrupted.db.
And probably also contributing, your router advertises its own IPv6 ULA as DNS server:
* Received 120 bytes from fe80::a3<redacted>de @ eth0
(…)
Recursive DNS server 1/1: fd96:be02:f0f6::1
DNS server lifetime:1800 sec
This would allow IPv6 clients to by-pass Pi-hole at their own discretion, and a client doing so would not be able to resolve pi.hole, and consequently may not be able to access Pi-hole's web UI.
That is, unless your router would be configured to use Pi-hole as its only upstream - is it?
You were correct about the corrupted database. I followed the commands you suggested and things are now up and running as expected. The integrity check said there was a mismatch in the indexes.
I have not setup the pihole to act as dns for the ipv6 clients. I only have a couple of devices that use ipv6 so it wasn't a huge priority when I set things up. You make a good point and I have some free time, so I will make sure to update it.
Thanks for your help!
Check your microSDXC card for corruption while you are at it 
Might as well do a new install with Debian 13 if it turns out to be so!