I discussed this already few times with others like @DL6ER. It still contains too much privacy relevant information - that’s why I provide only what’s exactly needed e. g. via PN.
Please note that
a) in reverse to my previous assumption this had and has nothing to do with the database lock mentioned in the topic above
b) „pihole -r“ did NOT fix this this time. Still
Pi-hole version is v5.15 (Latest: N/A)
AdminLTE version is v5.18.1 (Latest: N/A)
FTL version is v5.20.1 (Latest: N/A)
So it looks like the latest version information simply can’t be grabbed from (GitHub?).
During „pihole -r“:
[i] Restarting services...
[✓] Enabling pihole-FTL service to start on reboot...
[✓] Restarting pihole-FTL service...
fatal: unable to access 'GitHub - pi-hole/pi-hole: A black hole for Internet advertisements': Could not resolve host: github.com
fatal: unable to access 'GitHub - pi-hole/web: Pi-hole Dashboard for stats and more': Could not resolve host: github.com
fatal: unable to access 'GitHub - pi-hole/FTL: The Pi-hole FTL engine': Could not resolve host: github.com
/etc/pihole/pihole-FTL.conf: line 1: syntax error near unexpected token ;' /etc/pihole/pihole-FTL.conf: line 1: ; Am 2017-06-19 manuell erstellt …'
[✓] Deleting existing list cache
[✗] DNS resolution is currently unavailable
[✓] DNS resolution is now available
[i] Neutrino emissions detected...
Maybe this is a trap because during restart of itself it of course can not resolve GitHub hostnames.
I’m sure that is something one can work with.
Maximum compromise: I create the debug manually, screen and remove all privacy relevant content and provide it via PM.
Running „pihole updatechecker“ once updated the versions file and fixed this immediately:
Pi-hole version is v5.15 (Latest: v5.15)
AdminLTE version is v5.18.1 (Latest: v5.18.1)
FTL version is v5.20.1 (Latest: v5.20.1)
I bet all this started when you changed the way/interval updatechecker is run. It probably simply has not since the update (been a few hours…), until I ran it manually now. Probably related to
What is the content of your /etc/resolv.conf?. During an update FTL is restarted and might not be available for DNS resolution of your Pi device (in case you use Pi-hole for the device itself).
We are all volunteers doing Pi-hole stuff in our free time. Don't expect a 24/7 rapid response team. jfb already told you, the easiest way to help you is to provide a debug token - otherwise we need to crawl step by step which takes a long time and is exhausting (and will not improve our motivation to help you).
And in general my wish would be to remove at least whitelists and blocklists (among few other details I don’t remember precisely, I think mostly stuff exposing the internal network infrastructure, like a list of clients if I remember correctly) from the debug LOG. Not necessary for every issue hunting, sensitive information.
Thank you for working on Pi-Hole.
Back to topic:
But this way I am telling the host to use Pi-Hole. If I use another DNS server, that breaks using Pi-Hole for that machine, doesn’t it?
Yes, this machine would then use another DNS server instead.
I'm thinking of how to improve the installer to delay the script from running until DNS resolution is up.... Did you set DELAY_STARTUP in your pihole-FTL.conf?
That’s unfortunately not an option as it runs other services too. I prefer pointing to itself (Pi-Hole).
No I did not set this (yet), didn’t even know about this option. Delaying the update script for (in my case only few) seconds might be a good approach. At least for my semi-performant system I‘m confident it would work.
Maybe not a fixed number of seconds would be the way to go, but just waiting for Pi-Hole being operational and using that as trigger for running the updatechecker. Just my two cents, I‘m not a developer and I have no idea
Based on my current experience updating to latest versions (before:...
uname@server:~$ pihole -v
Pi-hole version is v5.15 (Latest: v5.15.1)
AdminLTE version is v5.18.1 (Latest: v5.18.2)
FTL version is v5.20.1 (Latest: v5.20.1)
)... I need to mention this is what I saw few (now: exactly 10) minutes after initiating the update:
uname@server:~$ pihole -v
Pi-hole version is v5.15.1 (Latest: N/A)
AdminLTE version is v5.18.2 (Latest: N/A)
FTL version is v5.20.1 (Latest: N/A)
Update: 20 minutes after the update I ran pihole updatechecker manually which solved it again immediately:
uname@server:~$ pihole -v
Pi-hole version is v5.15.1 (Latest: v5.15.1)
AdminLTE version is v5.18.2 (Latest: v5.18.2)
FTL version is v5.20.1 (Latest: v5.20.1)
Until this works reliably, I'll add running the updatechecker at the end of my little Pi-Hole update script. Update on that: noticed I already did so in October 2022 - wondering why this did not work yet. Added a sleep 30 after the update and before the pihole updatechecker for now.
Yes I do. Unfortunately I discovered your post after updating once again today (5.15.2 release). This time everything was fine (version shown / no "N/A"),
either because only FTL component was updated
or my manually added "pihole updatechecker" took care of it.
Here's the install.log, but from the 5.15.2 update - so I think it won't be useful, unfortunately:
install.log
[i] Installing scripts from /etc/.pihole...
^[[K [✓] Installing scripts from /etc/.pihole
[i] Installing configs from /etc/.pihole...
[i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
[i] Installing /etc/dnsmasq.d/01-pihole.conf...
^[[K [✓] Installed /etc/dnsmasq.d/01-pihole.conf
[i] Installing /etc/.pihole/advanced/06-rfc6761.conf...
^[[K [✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
[i] Installing sudoer file...
^[[K [✓] Installing sudoer file
[i] Installing latest Cron script...
^[[K [✓] Installing latest Cron script
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[i] Backing up /etc/dnsmasq.conf to /etc/dnsmasq.conf.old
[i] Testing man page installation
^[[K [✓] man pages installed and database updated
TBH I already had the „pihole updatechecker“ added to the update script since October 2022. What I now added before the 5.15.2 update is a sleep of 30 seconds between „pihole update“ and „pihole updatechecker“.
Will monitor this on the next update (as downgrades (without side effects) are not possible, are they?).