Gravity sync fails on new install with one host on backup step?

[jmpage2]

I'm not sure if this is a bug or not, but I'm a bit perplexed on what is causing the failure.

Installed & performed configuration of gravity-sync on two recently updated pi-holes.

pi-hole1 uname -a Linux pihole1 5.4.0-135-generic #152-Ubuntu SMP Wed Nov 23 20:19:22 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

pi-hole2 uname -a Linux raspberrypi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux

When I do gravity sync-compare it is shown that there are differences in the two (which makes sense as I have been running these two separately for years).

When I try to do push from the one that I want to be the primary the script fails with the following error; ∞ Performing backup of remote Gravity Databasepihole-FTL: invalid option -- 'sql' Try '/usr/bin/pihole-FTL --help' for more information ✗ Performing backup of remote Gravity Database

When I try to do pull from the one that I want to be the secondary the script fails with the following error; ∞ Performing backup of local Gravity Databasepihole-FTL: invalid option -- 'sql' Try '/usr/bin/pihole-FTL --help' for more information ✗ Performing backup of local Gravity Database

I have looked at gravity-sync script and can see where it checks the version of pi-hole and modifies the backup script (function backup_local_gravity), but I can't see where I should make the change to resolve the issue, which I assume is related to this pi-hole running on raspberry pi.

Any help would be appreciated.

[jmpage2]

Anyone?

[binarypatrick]

I would try updating your pihole instances to the latest. It looks like in v5.9 they changed the way the sqllite DB is called, which may be your problem.

https://github.com/pi-hole/pi-hole/releases/tag/v5.9

[jmpage2]

Thanks @BinaryPatrick I can give that a try. I had updated the pi-holes before attempting this, not sure why my revision is older.

[jmpage2]

@BinaryPatrick I was already running 5.14 actually but I did update both pi-holes to the latest version and now it's working, go figure.

[chrislange]

Hi @BinaryPatrick, I'm getting the failure on initial backup of the secondary but it fails with no output to suggest what might be wrong.

Also running PiHole on Docker:

• Docker Tag: 2023.02.2
• Pi-hole: v5.15.5
• FTL: v5.21

username@server:/DockerData/pihole$ gravity-sync push ∞ Initializing Gravity Sync (4.0.4) ✓ Loading gravity-sync.conf ✓ Detecting local Pi-hole installation gravitysync@10.55.60.92's password: ion gravitysync@10.55.60.92's password: gravitysync@10.55.60.92's password: ✓ Detecting remote Pi-hole installation gravitysync@10.55.60.92's password: ✓ Gravity Sync remote peer is configured ✓ Evaluating arguments: PUSH » Remote target gravitysync@10.55.60.92 ✓ Validating pathways to Pi-hole ✓ Validating pathways to DNSMASQ gravitysync@10.55.60.92's password: e ✓ Hashing the remote Gravity Database ✓ Comparing to the local Gravity Database ! Differences detected in the Gravity Database gravitysync@10.55.60.92's password: gravitysync@10.55.60.92's password: ✓ Hashing the remote DNS Records ✓ Comparing to the local DNS Records ! Differences detected in the DNS Records gravitysync@10.55.60.92's password: ! DNS CNAMEs not detected on the local Pi-hole gravitysync@10.55.60.92's password: ! Static DHCP Addresses not detected on the local Pi-hole ! Replication of Pi-hole settings is required ✗ Performing backup of remote Gravity Database username@server:/DockerData/pihole$

[vmstan]

Effective July 26, 2024, this project has been retired. Thank you for your use and enthusiasm for a project that began as a few lines of bash in a Slack channel and envolved into something far more complex, and used by many thousands of Pi-hole enthusiasts over the last four years.