I've been periodically issuing pihole -up to see if there's any updates to these test builds. Noticed today that it shows an update for core and goes through the motion of downloading and updating but re-running pihole -up shows a core update is still available. I'm seeing (edited) this on two pi3s that I've been running pihole on for eons.
Current Pi-hole version is release/v5.4 v5.3.1-63-g7bca5850
Current AdminLTE version is release/v5.6 v5.5-46-g690feb8b
Current FTL version is release/v5.9 vDev-1b4fdd4
Yeah, I didn't believe it either when I got the pop up from Mattermost that showed commits had been pushed to a protected branch.
As soon as that happened I went in and reset the head pointer to the original commit hard and removed the two additional commits from history. That required unprotecting the branch so I'm not really sure how the two stray commits were added in the first place.
Every action on our various repositories is logged and posted as messages on our Mattermost server so we can see everything that goes on.
Edit: I think the OP may have pulled the branch in the few minutes that the extra commits were on the branch. That would explain why this isn't being seen by most everyone else.
Okay, if the next bugfix commit doesn't resolve it then we can do a reset on the local /etc/.pihole repository. Sometimes the update check needs help to know what is an update and what isn't.
pi@gyre:~ $ pihole -up --check-only
[i] Checking for updates...
[i] Pi-hole Core: update available
[i] Web Interface: up to date
[i] FTL: up to date
[i] Warning: You are using FTL from a custom branch (release/v5.9) and might be missing future releases.
pi@gyre:~ $ pihole -v
Pi-hole version is release/v5.4 v5.3.1-63-g7bca5850 (Latest: v5.3.1)
AdminLTE version is release/v5.6 v5.5-46-g690feb8b (Latest: v5.5)
FTL version is release/v5.9 vDev-1b4fdd4 (Latest: v5.8.1)
Thanks, I'll take a look at the update check code to see why there is that discrepancy. May have to tweak the update checkers code to account for a few situations that we may not have considered in the past.
pi@gyre:~ $ pihole -up
[i] Checking for updates...
[i] Pi-hole Core: update available
[i] Web Interface: up to date
[i] FTL: up to date
[i] Warning: You are using FTL from a custom branch (release/v5.9) and might be missing future releases.
[i] Pi-hole core files out of date, updating local repo.
[✓] Check for existing repository in /etc/.pihole
[i] Update repo in /etc/.pihole...
: Could not update local repository. Contact support.
pi@gyre:/etc/.pihole $ git status
On branch release/v5.4
Your branch and 'origin/release/v5.4' have diverged,
and have 1 and 2 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
nothing to commit, working tree clean
That got it going again. The only anomaly I had is:
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[✗] Failure in logrotate installation function.
last of the update output and new check:
Update Complete!
Current Pi-hole version is release/v5.4 v5.3.1-64-g7f4bb24f
Current AdminLTE version is release/v5.6 v5.5-46-g690feb8b
Current FTL version is release/v5.9 vDev-1b4fdd4
pi@gyre:/etc/.pihole $ pihole -up --check-only
[i] Checking for updates...
[i] Pi-hole Core: up to date
[i] Web Interface: up to date
[i] FTL: up to date
[i] Warning: You are using FTL from a custom branch (release/v5.9) and might be missing future releases.
[✓] Everything is up to date!
It's been mentioned that the Cross is misleading. It probably could be worded better, it's related to the line above it, no logrotate file was installed since there was one existing.
It is git so there's always a half-dozen ways to do the same thing. The end goal is what we are concerned about and not the exact commands used to get there.
