Just one more to be sure:
Try if bash -x pihole -g might reveal more details.
I'm just about to log off (well past midnight here), so might not be available to answer straight away.
1 Like
Seems pretty much the same:
192.168.0.0/24 dev wlan0 proto dhcp scope link src 192.168.0.49 metric 303
pi@pi2:/tmp $ nslookup -type=A raw.githubusercontent.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: raw.githubusercontent.com
Address: 185.199.110.133
Name: raw.githubusercontent.com
Address: 185.199.108.133
Name: raw.githubusercontent.com
Address: 185.199.109.133
Name: raw.githubusercontent.com
Yeah the curl you run before already proved this bit was working properly.
I should have read that bit more careful 
I'm also signing out.
NN
Nothing useful, but lots of pretty colors, at least on my screen:
pi@pi2:/tmp $ bash -x pihole -g
+ readonly PI_HOLE_SCRIPT_DIR=/opt/pihole
+ PI_HOLE_SCRIPT_DIR=/opt/pihole
+ setupVars=/etc/pihole/setupVars.conf
+ PI_HOLE_BIN_DIR=/usr/local/bin
+ readonly FTL_PID_FILE=/run/pihole-FTL.pid
+ FTL_PID_FILE=/run/pihole-FTL.pid
+ readonly colfile=/opt/pihole/COL_TABLE
+ colfile=/opt/pihole/COL_TABLE
+ source /opt/pihole/COL_TABLE
++ [[ -t 1 ]]
+++ tput colors
++ [[ 8 -ge 8 ]]
++ COL_BOLD=''
++ COL_ULINE=''
++ COL_NC=''
++ COL_GRAY=''
++ COL_RED=''
++ COL_GREEN=''
++ COL_YELLOW=''
++ COL_BLUE=''
++ COL_PURPLE=''
++ COL_CYAN=''
++ COL_WHITE=''
++ COL_BLACK=''
++ COL_LIGHT_BLUE=''
++ COL_LIGHT_GREEN=''
++ COL_LIGHT_CYAN=''
++ COL_LIGHT_RED=''
++ COL_URG_RED=''
++ COL_LIGHT_PURPLE=''
++ COL_BROWN=''
++ COL_LIGHT_GRAY=''
++ COL_DARK_GRAY=''
++ TICK='[✓]'
++ CROSS='[✗]'
++ INFO='[i]'
++ QST='[?]'
++ DONE=' done!'
++ OVER='\r'
+ utilsfile=/opt/pihole/utils.sh
+ source /opt/pihole/utils.sh
+ [[ 1 = 0 ]]
+ case "${1}" in
+ [[ ! 1000 -eq 0 ]]
++ command -v sudo
+ [[ -x /usr/bin/sudo ]]
+ exec sudo bash pihole -g
[✗] DNS resolution is currently unavailable
[✗] DNS resolution is not available
Thanks for keeping at it I'll poke around, maybe I'll stumble on something.
Last one
pi@ph5b:~ $ grep 'DNS resolution is currently unavailable' /opt/pihole/gravity.sh -B5 -A10
exit 1
fi
# Determine error output message
if pgrep pihole-FTL &> /dev/null; then
echo -e " ${CROSS} DNS resolution is currently unavailable"
else
echo -e " ${CROSS} DNS service is not running"
"${PIHOLE_COMMAND}" restartdns
fi
[..]
What does below one show?
pgrep pihole-FTL
I believe I've found the issue. More in a bit, but I've got a binary named timeout in /usr/local/bin that's taking precedence over /usr/bin/timeout, and I think that's messing up anything that uses that function. I stuck a set -x at the beginning of the gravity_CheckDNSResolutionAvailable() function in /opt/pihole/gravity.sh and ran the first check to see the output:
pi@pi2:/opt/pihole $ timeout 4 getent hosts raw.githubusercontent.com
Timeout = 4 seconds
Entered Min Brightness value is not a number
Found the path that it was using, which is a timeout thing that mucks with the display.
I'm temporarily modifying gravity.sh to force it to use /usr/bin/timeout instead and will report back shortly, but that looks like it.
3 Likes
That seems to have done the trick:
pi@pi2:/opt/pihole $ pihole -g
[i] Neutrino emissions detected...
[✓] Pulling blocklist source list into range
[✓] Preparing new gravity database
[i] Using libz compression
[i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
[✓] Status: Retrieval successful
[i] Analyzed 145625 domains
[i] List stayed unchanged
[✓] Creating new gravity databases
[✓] Storing downloaded domains in new gravity database
[✓] Building tree
[✓] Swapping databases
[✓] The old database remains available.
[i] Number of gravity domains: 145625 (145625 unique domains)
[i] Number of exact blacklisted domains: 0
[i] Number of regex blacklist filters: 0
[i] Number of exact whitelisted domains: 0
[i] Number of regex whitelist filters: 0
[✓] Flushing DNS cache
[✓] Cleaning up stray matter
[✓] FTL is listening on port 53
[✓] UDP (IPv4)
[✓] TCP (IPv4)
[✓] UDP (IPv6)
[✓] TCP (IPv6)
[✓] Pi-hole blocking is enabled
What I did was to replace all instances of timeout with /usr/bin/timeout (except in the sqlite commands, where I initially broke it). I don't know if that's a practical fix for the general case though.
Glad we finally nailed this one. 
Could you elaborate a bit here?
How did that diverging timeout binary end up in your new installation?
(Why) do you require to keep it?
That would work temporarily , but will be overwritten by Pi-hole updates.
I'd also like to point out that this would affect any script (so not just Pi-hole) that relies on the call contract of the conventional timeout and may possibly break dependent code.
Another approach would thus be to simply rename that other binary.
In case that's specifically needed for some other software you are running on the system hosting Pi-hole, it may be easier to adopt just that for the alternate name.
If you don't require that offending timeout at all, then you could also consider removing it altogether.
1 Like
First of all, thank you and everyone else for your help with this. Although I was finally able to sort it out on my own, without your help I never would have figured out where to start looking.
That particular timeout executable is part of a screen dimmer for the Pi that I use. Fortunately, the executable is called by a shell script that's trivially modified, and that package is unlikely to change, so I just renamed the executable and verified that which timeout now point to the correct one in /usr/bin.
With all the testing and moving things around, I'd like to do a clean install. Can I just re-run the install script?
1 Like
Foolisch of them to select timeout as a name as that command is present on most all distro's:
pi@ph5b:~ $ dpkg -S /usr/bin/timeout
coreutils: /usr/bin/timeout
pi@ph5b:~ $ dpkg -L coreutils
/.
/bin
/bin/cat
/bin/chgrp
/bin/chmod
/bin/chown
/bin/cp
/bin/date
/bin/dd
/bin/df
/bin/dir
/bin/echo
/bin/false
/bin/ln
/bin/ls
/bin/mkdir
[..]
/usr/bin/timeout
For a clean install you would have to uninstall Pi-hole first.
But if I recollect correctly, the uninstall procedure will ask which dependencies should be uninstalled and they are a bit tricky to answer if dont investigate first if you still need some of those packages..
Why not leave it as is?
Also consider the teleporter if want to move configurations around:
http://pi.hole/admin/settings.php?tab=teleporter
Funny that you should mention that -- This all started with me googling "move pi-hole configuration to a new machine" and discovering teleporter. So I had that, figured I'd just do a quick install, and the rest is historically documented in this thread.
The only remaining issue was to reset (or in my case, remove, since the device isn't accessible externally) the password, which was easy to do.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.