AdminLTE versions error

Help
1

Hello,

during the last update of the Pi-Hole components I noticed the following:

root@pihole-backup-II:~# pihole -up
  [✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 8.2.7
  [✓] 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!
root@pihole-backup-II:~# pihole -v
  Pi-hole version is v5.17.2 (Latest: v5.17.2)
  AdminLTE version is v5.20.2 (Latest: null)
  FTL version is v5.23 (Latest: v5.23)

The AdminLTE version is correct, but shows Latest: null.
The system seems to work without any problems so far.
What could be the cause and how can I correct the error?

Pi-hole is installed on an RPi Zero W running DietPi v8.22.3.(Debian Bookworm)

Best regards,
Carsten

2

This is due to the recent PSA: Renaming the web repo (from AdminLTE to simply web).

Running pihole -up should fix it to look like

$ pihole -v
  Pi-hole version is v5.17.2 (Latest: v5.17.2)
  web version is v5.20.2 (Latest: v5.20.2)
  FTL version is v5.23 (Latest: v5.23)
3

@Bucking_Horn

Unfortunately, the erroneous display still exists, even the commands apt update, apt upgrade, apt dist-upgrade executed before did not change anything.

root@pihole-backup-II:~# pihole -v
  Pi-hole version is v5.17.2 (Latest: v5.17.2)
  AdminLTE version is v5.20.2 (Latest: null)
  FTL version is v5.23 (Latest: v5.23)
4

How did you install Pi-hole on DietPi?

@MichaIng, this may be specific to DietPi's installer for Pi-hole, which employs special management for the web server portion?

5

Yes, I have installed it under dietpi-software.
But I must say that another Pi-hole on a RPi Zero W(Buster) and a Pi-hole on a RPi 4(Bullseye) does not show this behavior.

Could perhaps a pihole -r fix the error?

6

But while running pihole -up, no tool or script from DietPi side are involved. There is no web server configuration involved. As you can see, user is running the version check directly on CLI

According the user, file /etc/pihole/versions seems to be missing some information. I guess it's created / updated by pihole -up?

7

@Bucking_Horn, @Joulinar

It seems I entered one the command not quite correctly, here is the correct output:

root@pihole-backup-II:~# cat /etc/pihole/versions
CORE_BRANCH=master
WEB_BRANCH=master
FTL_BRANCH=master
CORE_VERSION=v5.17.2
WEB_VERSION=v5.20.2
FTL_VERSION=v5.23
GITHUB_CORE_VERSION=v5.17.2
GITHUB_WEB_VERSION=null
GITHUB_FTL_VERSION=v5.23
CORE_HASH=60b6a101
GITHUB_CORE_HASH=60b6a101
WEB_HASH=3dd57522
GITHUB_WEB_HASH=3dd57522
FTL_HASH=d201776e
GITHUB_FTL_HASH=1a114133
8

This is what the update checker script does:

curl -s 'https://api.github.com/repos/pi-hole/web/releases/latest' 2> /dev/null | jq --raw-output .tag_name

Checking the page, this should currently return v5.20.2.

Ah, looks like the updater script is faulty/old version or such, that it still tries to check the version of the "AdminLTE" repository, which has been renamed. And the curl does not follow redirects, hence the empty/null makes sense. Since the updater script is part of core, which is shown as being on latest version already, this is strange indeed.

Can you check your script:

grep get_remote_version /opt/pihole/updatecheck.sh
stat /opt/pihole/updatecheck.sh
9 
root@pihole-backup-II:~# grep get_remote_version /opt/pihole/updatecheck.sh
function get_remote_version() {
GITHUB_CORE_VERSION="$(get_remote_version pi-hole)"
    GITHUB_WEB_VERSION="$(get_remote_version AdminLTE)"
GITHUB_FTL_VERSION="$(get_remote_version FTL)"
    GITHUB_DOCKER_VERSION="$(get_remote_version docker-pi-hole)"
root@pihole-backup-II:~# stat /opt/pihole/updatecheck.sh
 Datei: /opt/pihole/updatecheck.sh
 Größe: 4270            Blöcke: 16         EA Block: 4096   reguläre Datei
Gerät: 179/2    Inode: 261177      Verknüpfungen: 1
Zugriff: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Zugriff: 2023-09-26 19:16:10.644859974 +0200
Modifiziert: 2023-09-26 19:16:10.644859974 +0200
Geändert: 2023-09-26 19:16:10.644859974 +0200
Geburt: 2023-09-26 19:16:10.644859974 +0200
10

As expected, something with your last update went wrong. Since the versions file contains CORE_VERSION=v5.17.2, the local repository at /etc/.pihole must have been updated, but the scripts were not successfully copied to /opt/pihole:

  • v5.17.2 was released two days ago, while the modify timestamp is from more than two weeks ago.
  • The updatechecker.sh of this version checks the web UI version via get_remote_version web, while your's does via get_remote_version AdminLTE, which is how it was until v5.17.1.

A repair should solve it:

pihole -r

Select "Repair" to retain existing settings.

1 Like
11

@MichaIng

It's getting weirder and weirder. After I edited the "versions" file under /etc/pihole as a workaround and changed the entry NULL to 5.20.2, everything seemed to be fine.

Then I ran pihole -r again and got an error message about incorrect OS version or something like that.

It was pointed out to run the following command:

...
sudo PIHOLE_SKIP_OS_CHECK=true pihole - r
...

I did that and selected the “Repair” option, but there were no error messages whatsoever.
If I now run pihole - v repeatedly, I get the following output:

...
root@pihole-backup-II:~# pihole -v
Pi-hole version is v5.17.2 (Latest: v5.17.2)
web version is v5.20.2 (Latest: N/A)
FTL version is v5.23 (Latest: v5.23)
...

It now appears N/A instead of NULL.

12

but there were no error messages whatsoever.

What was the last output, respectively was there a message that it has successfully completed?

As you use Debian Bookworm, the OS version should be supported since a long time. Can you check this:

cat /etc/os-release

At least it say "web version" now instead of "AdminLTE version", so the script has been updated. The -v command does not actually check for updates, as long as the versions file does still exist. Please enforce an update check

pihole updatechecker
13

@MichaIng

root@pihole-backup-II:~# cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
NAME="Raspbian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="RaspbianForums - Raspbian"
BUG_REPORT_URL="RaspbianBugs - Raspbian"

Pihole updatechecker initially returned a "fatal error", after repeated execution there is no longer any output, but pihole -v now returns correct data.

This is really a bit crazy.

Edit: Sorry, the problem still exists.

root@pihole-backup-II:~# pihole updatechecker
Schwerwiegend: konnte nicht auf 'GitHub - pi-hole/FTL: The Pi-hole FTL engine' zugreifen: Empty reply from server

I might have another hint. I have upgraded from Bullseye to Bookworm using your script on several DietPi systems, I think possibly on this system too. Could this perhaps be the cause of this strange phenomenon?

14

Thanks for chiming in (both Joulinar and MichaIng). :wink:

I don't know much about the DietPi installer, but I was wondering whether calling pihole -up would be the correct way to upgrade a Pi-hole that was installed using that DietPi installer, or if there's a preferred alternative?

That file should NOT be manually edited.
Feigning some release info for a potentially incomplete or partially upgraded component may well have caused side effects on the repair option.

15

@Bucking_Horn

As written above, editing didn't help in the long run.

16

Yes that's the correct way on DietPi as well.

2 Likes
17

It is the correct way.

The os-release file looks correct. This returns 12, doesn't it?

grep VERSION_ID /etc/os-release | cut -d '=' -f2 | tr -d '"'

And this:

dig +short -t txt versions.pi-hole.net @ns1.pi-hole.net

returns

"Raspbian=10,11 Ubuntu=20,22,23 Debian=10,11,12 Fedora=36,37,38 CentOS=8,9"

?

However, lets not focus on this one too much. Report back if on next pihole -up it again tells you have an unsupported OS (version).

Probably one of the used tools is damaged, or a library, which might also cause the OS check issue? To debug the script:

bash -x /opt/pihole/updatecheck.sh

The error message sounds like it could be the git ls-remote "https://github.com/pi-hole/FTL" --tags master call. That one however seems to have succeeded before, as there is an FTL hash in the versions file :thinking:.

EDIT: Hah, indeed it is, and I can replicate here:

root@VM-Bookworm:~# git ls-remote "https://github.com/pi-hole/FTL" --tags master
fatal: unable to access 'https://github.com/pi-hole/FTL/': Empty reply from server

Repeating this after some tests with the other repos, suddenly it succeeds:

root@VM-Bookworm:~# git ls-remote "https://github.com/pi-hole/FTL" --tags master
1a11413385eee8992b12b662cd37c32e55da4f6d        refs/heads/master

Hmm looks like a GitHub server issue.

18

Working on my installations (Armbian 21 and Raspbian 10):

$ git ls-remote "https://github.com/pi-hole/FTL" --tags master
1a11413385eee8992b12b662cd37c32e55da4f6d	refs/heads/master
19

My edit was too late. Yes it succeeds now a minute later. Probably some GitHub server/network issues. Great when external issues overlap with local issues you want to debug :smile:.

So @Falconcrest as your Pi-hole scripts are now on latest versions and the versions file content is correct as well, I think there is no issue with your Pi-hole anymore. However, have an eye on next pihole -up, whether the OS check still fails, and whether the update check still fails (for another reason than this GitHub server issue).

EDIT: It happens by times on the other repos as well, in about 1 of 10 calls:

root@VM-Bookworm:~# git ls-remote "https://github.com/pi-hole/pi-hole" --tags master
fatal: unable to access 'https://github.com/pi-hole/pi-hole/': Empty reply from server
...
root@VM-Bookworm:~# git ls-remote "https://github.com/pi-hole/web" --tags master
fatal: unable to access 'https://github.com/pi-hole/web/': Empty reply from server

Hopefully this unreliable access issues are resolved soon, otherwise we do now know about the problem, in case other users report issues with their update checkers as well.

1 Like
20

I would like to thank everyone involved for their time and effort in solving the problem.

I almost lost my composure for a short time because the pihole version suddenly showed Latest: N/A. :woozy_face:

Thanks

1 Like