all updates are showing RED:
seems pihole updatechecker fixed it:
pi@raspberrypi:[/var/log] $ pihole updatechecker
pi@raspberrypi:[/var/log] $ pihole -v
Pi-hole version is v5.14.1 (Latest: v5.14.1)
AdminLTE version is v5.17 (Latest: v5.17)
FTL version is v5.19.2 (Latest: v5.19.2)
Whats the reason now working? What did updatechecker do to fix?
It checks github to see what the current versions are, so that you can be notified of any available updates. It runs periodically. I noticed the same behaviour after a recent update – pihole -v would report N/A until updatechecker was ran, and then it showed the correct current versions. I assumed that had I waited long enough after the update it would have ran automatically and this wouldn't be noticeable.
$ pihole -v
Pi-hole version is v5.14.1 (Latest: N/A)
AdminLTE version is v5.17 (Latest: N/A)
FTL version is v5.19.1 (Latest: N/A)
$ pihole updatechecker
$ pihole -v
Pi-hole version is v5.14.1 (Latest: v5.14.1)
AdminLTE version is v5.17 (Latest: v5.17)
FTL version is v5.19.1 (Latest: v5.19.1)
1 Like
strange, after every raspi reboot the version in padd.sh are AGAIN outdated and pihole updatechecker needs to run again ... why is it not PERSISTANT?
Sounds like your sdcard is going bad and it's set to read-only mode.
@DanSchaper the github info will be deleted
see the details:
CORE_BRANCH=master
WEB_BRANCH=master
FTL_BRANCH=master
CORE_VERSION=v5.14.1
WEB_VERSION=v5.17
FTL_VERSION=v5.19.2
GITHUB_CORE_VERSION=
GITHUB_WEB_VERSION=
GITHUB_FTL_VERSION=
CORE_HASH=21026d9
GITHUB_CORE_HASH=
WEB_HASH=da2764e5
GITHUB_WEB_HASH=
FTL_HASH=844c8b9f
GITHUB_FTL_HASH=
more details
drwxrwxr-x 4 pihole pihole 20480 Nov 22 21:09 pihole
/etc/pihole/
-rw-r--r-- 1 root root 324 Nov 22 17:58 versions
root@raspberrypi[/etc/pihole] # cat versions
CORE_BRANCH=master
WEB_BRANCH=master
FTL_BRANCH=master
CORE_VERSION=v5.14.1
WEB_VERSION=v5.17
FTL_VERSION=v5.19.2
GITHUB_CORE_VERSION=v5.14.1
GITHUB_WEB_VERSION=v5.17
GITHUB_FTL_VERSION=v5.19.2
CORE_HASH=21026d9
GITHUB_CORE_HASH=21026d94
WEB_HASH=da2764e5
GITHUB_WEB_HASH=da2764e5
FTL_HASH=844c8b9f
GITHUB_FTL_HASH=844c8b9f
pi@raspberrypi:[~] $ pihole -v
Pi-hole version is v5.14.1 (Latest: v5.14.1)
AdminLTE version is v5.17 (Latest: v5.17)
FTL version is v5.19.2 (Latest: v5.19.2)
REBOOT:
-rw-r--r-- 1 root root 281 Nov 22 21:13 versions
CORE_BRANCH=master
WEB_BRANCH=master
FTL_BRANCH=master
CORE_VERSION=v5.14.1
WEB_VERSION=v5.17
FTL_VERSION=v5.19.2
GITHUB_CORE_VERSION=
GITHUB_WEB_VERSION=
GITHUB_FTL_VERSION=
CORE_HASH=21026d9
GITHUB_CORE_HASH=
WEB_HASH=da2764e5
GITHUB_WEB_HASH=
FTL_HASH=844c8b9f
GITHUB_FTL_HASH=
pihole updatechecker fills the missing entries again
according to cron.d file it should update after reboot??
pi@raspberrypi:[/etc/cron.d] $ cat pihole
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Updates ad sources every week
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.
#
#
#
# This file is under source-control of the Pi-hole installation and update
# scripts, any changes made to this file will be overwritten when the software
# is updated or re-installed. Please make any changes to the appropriate crontab
# or other cron file snippets.
# Pi-hole: Update the ad sources once a week on Sunday at a random time in the
# early morning. Download any updates from the adlists
# Squash output to log, then splat the log to stdout on error to allow for
# standard crontab job error handling.
11 4 * * 7 root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updateGravity >/var/log/pihole/pihole_updateGravity.log || cat /var/log/pihole/pihole_updateGravity.log
# Pi-hole: Flush the log daily at 00:00
# The flush script will use logrotate if available
# parameter "once": logrotate only once (default is twice)
# parameter "quiet": don't print messages
00 00 * * * root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole flush once quiet
@reboot root /usr/sbin/logrotate --state /var/lib/logrotate/pihole /etc/pihole/logrotate
# Pi-hole: Grab remote and local version every 24 hours
53 17 * * * root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker
@reboot root PATH="$PATH:/usr/sbin:/usr/local/bin/" pihole updatechecker reboot
Changes to any files won't be persisted and lost on a reboot if...
Did you check whether that's the case and for respective kernel errors yet, e.g. by running:
sudo mount | grep '(ro'
dmesg -l emerg,alert,crit,err
no traces of card errors
I can check with different card
I'm not entirely sure whether my grep would generate a proper match on all OS varieties. 
To be safe, you may want to inspect the full sudo mount output and look for ro or read-only mounts.
not the sd card, checked with a different one - same behaviour
pi@raspberrypi:[~] $ sudo mount | grep -i ro
proc on /proc type proc (rw,relatime)
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,flush,errors=remount-ro)
after every reboot the versions file is somehow cut
pihole updatechecker fills it again, and since some updates ago it is no longer running all 10 mins only once a day, and SHOULD after reboot - but seems no longer work after last upgrade round for pihole
I think it's running after every reboot but fails to fetch the remote versions and fills the file with no information at these spots.
.. so a program error in that case? never faced that before ...
We changes some things in the updatechecker, but I don't think it's an error by itself, but rather an interplay of some system settings that trigger the issue. Not all users/installations are affected.
Do you use Pi-hole as DNS server for your Pi device?
yes, have pihole with unbound installed
No, this is not what I meant.
What's in your /etc/resolv.conf
nameserver 127.0.0.1
I think this is the problem here.
Change it to something else, e.g.
nameserver 8.8.8.8 and see if the issue persists after a reboot.
isnt /etc/resolv.conf content overwritten by the system at every reboot?
Depends on the system. But if what you just printed is all there is in the file, then no.