Is gravity.db missing in v5.0?

OK, looks like the gravity db didn't get properly created. does pihole -g -r work now?

It worked to create gravity.db but dns is still not running even after running sudo service pihole-FTL restart.

pihole -g -r
  [✓] Restoring from migration backup
  [i] Creating new gravity database
  [i] Migrating content of /etc/pihole/adlists.list into new database
  [i] Migrating content of /etc/pihole/blacklist.txt into new database
  [i] Migrating content of /etc/pihole/whitelist.txt into new database
  [i] Migrating content of /etc/pihole/regex.list into new database
  [i] Neutrino emissions detected...
  [✓] Pulling blocklist source list into range

  [✓] Preparing new gravity database
  [i] Target:
  [✓] Status: Retrieval successful
  [i] Received 55200 domains

  [i] Target:
  [✓] Status: Retrieval successful
  [i] Received 26857 domains

  [i] Target:
  [✓] Status: Retrieval successful
  [i] Received 34 domains

  [i] Target:
  [✓] Status: Retrieval successful
  [i] Received 2701 domains

  [✓] Storing downloaded domains in new gravity database
  [✓] Building tree
  [✓] Swapping databases
  [i] Number of gravity domains: 84792 (82385 unique domains)
  [i] Number of exact blacklisted domains: 2
  [i] Number of regex blacklist filters: 2
  [i] Number of exact whitelisted domains: 13
  [i] Number of regex whitelist filters: 0
  [✗] pihole-FTL: no process found
  [✓] Cleaning up stray matter
  [✓] Restarting DNS server

  [✗] DNS service is NOT running

The issue may also be the sqlite3 version on your system, maybe gravity cannot work with it.

What is the output of

sqlite3 --version
ls -lh /etc/pihole/gravity.db
sqlite3 /etc/pihole/gravity.db "SELECT * FROM vw_gravity LIMIT 10;"


sqlite3 --version
3.16.2 2017-01-06 16:32:41 a65a62893ca8319e89e48b8a38cf8a59c69a8209

ls -lh /etc/pihole/gravity.db
-rw-rw-r-- 1 pihole pihole 4.9M May 11 15:59 /etc/pihole/gravity.db

sqlite3 /etc/pihole/gravity.db "SELECT * FROM vw_gravity LIMIT 10;"

The file has been created around 16:00, the errors in FTL's log are from earlier

Are they still in the log when you restart pihole-FTL?

Yes the log looks the same right now, even after restarting pihole-FTL a couple of times.

Very strange. The message

is generated before we even use the SQLite3 engine, it comes when FTL cannot stat the database.

How about

sudo -u pihole stat /etc/pihole/gravity.db


sudo -u pihole stat /etc/pihole/gravity.db
  File: /etc/pihole/gravity.db
  Size: 5066752   	Blocks: 9920       IO Block: 4096   regular file
Device: 801h/2049d	Inode: 5653058     Links: 1
Access: (0664/-rw-rw-r--)  Uid: (  999/  pihole)   Gid: (  999/  pihole)
Access: 2020-05-11 15:59:05.529850765 -0600
Modify: 2020-05-11 15:59:32.747928484 -0600
Change: 2020-05-11 16:24:25.772646336 -0600
 Birth: -

Sorry, got v late and had to go to bed!

It's a long shot, but maybe we will find something useful from running some debugging on FTL

It may just be that 5.0 was the straw that broke the camels back as far as the Pogoplug goes (without one here to test, it's difficult to say!)

No worries and I really appreciate all the help trying to make this work.

I remembered this morning that way back when I installed the previous 4.x version before 5.0, I had "installed from source" using the web page on this site because the regular installation method was failing in that version as well. It worked really well going that route but trying to install from source for v5.0 is not working this time.

I think I'll just go back a version or just use a more modern piece of hardware to be able to run the new version. I don't want to bother all of you any more for something that is likely obsolete and an edge case, unless you were interested in continuing.

Again, thanks for all your help.

I would be curious to see if debugging as described on the docs page yields anything interesting. At least then we might be able to say "Ah, this is why it doesn't work and we can fix that with no problem" or "Ah, this is why it doesn't ... and won't work"

I'm happy to report I have successfully updated to v5.0 on the Pogoplug Pro.

I went back to the beginning and tried to install it from source and it worked. I thought I had tried that yesterday but I must have missed a step or did something wrong. The only scare was after completion when I ran pihole -v and realized it was still on checkout core tweak/binary_detection that you had me switch to yesterday. I went ahead and ran pihole checkout master and nothing broke and all was working correctly with the change.

I then attempted to install from source on another version 4.4 I was running on another Pogoplug. That one failed but I think it's because it's an older Pogoplug E02 running armv5tel and I need 6 or better. That being said, the armv5tel runs 4.4 just fine when I install from source. No big deal.

So just wanted to let you know and I really appreciate all the help!


Oh and fyi, I will do the debugging you asked about in the next few days when I can.

Was happily running 4.x on Pogoplug E02. Saw there was an update and immediately proceeded to update.
Everything broke. FTL never installed in the past, so wasn't expecting anything different.
So cloned and compiled FTL locally and replaced the one in /usr/bin. Things were somewhat running.
No gravity.db. Manually ran the command to create the db. Good, but now I can't change anything.
Permission denied. After spending a lot of time trying to fix this, did a pihole -uninstall.
Then downloaded the install script, modified it to use my compiled FTL and installed. Voila!

Thanks for sharing that.

As we have two German users with a very similar problem in Nach updaten auf Pihole v5, zeigt das Dashboard nichts an, would you be so kind as to elaborate on how you did that exactly?

    if true; then
        # get sha1 of the binary we just downloaded for verification.
        curl -sSL --fail "${url}/${binary}.sha1" -o "${binary}.sha1"

        # If we downloaded binary file (as opposed to text),
        if true; then
            printf "transferred... "

            # Before stopping FTL, we download the macvendor database
            curl -sSL "" -o "${PI_HOLE_CONFIG_DIR}/macvendor.db" || true
            chmod 644 "${PI_HOLE_CONFIG_DIR}/macvendor.db"
            chown pihole:pihole "${PI_HOLE_CONFIG_DIR}/macvendor.db"

            # Stop pihole-FTL service if available
            stop_service pihole-FTL &> /dev/null

            # Install the new version with the correct permissions
            install -T -m 0755 /root/FTL/git/FTL/pihole-FTL /usr/bin/pihole-FTL

Changes are on line 2208, 2213 and 2225. On line 2225, give the path of the self-compiled ftl binary.


Same exact issue, updated from 4.0. Same error, missing gravity.db.

sudo bash -x /etc/.pihole/automated\ install/

Fixed it for me. Thank you!

I had also the same issue and

sudo bash -x /etc/.pihole/automated\ install/

worked for me.

Great fix. Nowhere I found any reasonable hint until I discovered this thread. And spent hours.
I am sure that the upgrade process must have a bug. I did it from a pretty fresh v4.x and it failed as well with the missing .db.
Thanks very much to all!

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.