Latest version check returns "N/A" for Pi-hole

Expected Behaviour:

pihole -v returns the latest available versions

Actual Behaviour:

pihole -v returns N/A for Pi-hole.

user@host:~$ pihole -v
  Pi-hole version is v5.14.2 (Latest: N/A)
  AdminLTE version is v5.18 (Latest: v5.18)
  FTL version is v5.20 (Latest: v5.20)
user@host:~$ pihole -up
  [✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 8.1.14
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for dialog
  [✓] Checking for ca-certificates

  [i] Checking for updates...
  [i] Pi-hole Core:	up to date
  [i] Web Interface:	up to date
  [i] FTL:		up to date

  [✓] Everything is up to date!
user@host:~$ pihole -v
  Pi-hole version is v5.14.2 (Latest: N/A)
  AdminLTE version is v5.18 (Latest: v5.18)
  FTL version is v5.20 (Latest: v5.20)
user@host:~$ 

Additional notes:

This happened during automatic version check few hours ago.

Does this happen if the repository is not available or sth. like that?
Clearly something in the update/sources infrastructure, my Pi-Hole is totally fine.

Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:

pihole -d

or do it through the Web interface:

Tools > Generate Debug Log

Unfortunately I already ran pihole -r (repair) which solved this issue immediately. Therefore I don't have logs anymore. Solved for me and now.

Possibly related to Deleting ONE entry in Pi-hole diagnosis triggers deleetion of 1616 (invisible) messages which fails.

A repair does not delete existing logs.

I documented what happened (root cause) checking the logs @ Database locked (one symptom: deleting ONE entry in Pi-hole diagnosis triggers deleetion of 1616 (invisible) messages which fails) - #3 by bcutter.

@jfb Immediately after updating Pi-hole to the latest release, I see the same again:


Therefore I removed the „solved“ of this topic.

Please assist. I won’t provide a full debug token - tell me what you need.

Otherwise I‘ll just restartdns or do a repair again - so this will never get solved.

We need a debug token.

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.

—————

„etc/pihole/versions“ confirms my assumption:

CORE_BRANCH=master
WEB_BRANCH=master
FTL_BRANCH=master
CORE_VERSION=v5.15
WEB_VERSION=v5.18.1
FTL_VERSION=v5.20.1
GITHUB_CORE_VERSION=
GITHUB_WEB_VERSION=
GITHUB_FTL_VERSION=

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

Details on the updatechecker change:

So far, thanks for letting me talk to myself here :smile:

Unrelated to your issue, but you can fix

/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 …'

Comments need to start with #; to avoid issues with PHP and bash reading this file. (See Update pihole-FTL.conf.5 - specify comment formats by jgrisham · Pull Request #4081 · pi-hole/pi-hole · GitHub for more details)

https://docs.pi-hole.net/ftldns/configfile/


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).

2 Likes

Thanks, stumbled over this in the past already. Replaced all lines starting with ; with # instead.

resolv.conf has

  • nameserver with IP of Pi-Hole and
  • search with hostname of router

By the way many thanks actually reading and reacting to my postings. :slightly_smiling_face:

You need both in the correct order #;

__

You should change the nameserver to an external DNS server. Otherwise, the updatechecker will fail again after an update.

I don’t expect that. I only expect saying more than „debug token“. I did a lot of investigation already on my own (crawling and spending time :slight_smile: ), both here as well as at Database locked (one symptom: deleting ONE entry in Pi-hole diagnosis triggers deleetion of 1616 (invisible) messages which fails) - work you don’t need to do in the first place.

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 :slight_smile:

This will mitigate the issue by switching the updatechecker with the gravity run:

Gravity has a check for DNS availability, which should give FTL a few more seconds to fully start up.

This is the part of gravity checking the DNS resolution

[✗] DNS resolution is currently unavailable
[✓] DNS resolution is now available
1 Like

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)

Summary: the mentioned fix Run updatechecker after gravity by yubiuser · Pull Request #5137 · pi-hole/pi-hole · GitHub did NOT work in my case.

/var/log/pihole/FTL.log.1 saved if of interest.


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.

Mhh.. running gravity before updatechecker should have given FTL enought time to get completly ready.
Do you still have /etc/pihole/install.log ?

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