Upgrade from 6.0.4 to 6.0.5 not taking place

Help Community Help
1

Hello:

The issue I am facing:
I have been running pi-hole on a VM in my Linux Devuan box since mid-2011, always worked prefectly well and every upgrade was smooth using the PIHOLE_SKIP_OS_CHECK=true pihole -r stanza, no issues to mention.

For some reason, the last upgrade (6.0.4 to 6.0.5) did not upgrade the Core and Web versions.

The last lines of the process are:

--- snip ---
[✓] Done.

  [i] The install log is located at: /etc/pihole/install.log
  [✓] Update complete! 

Core version is v6.0.4 (Latest: v6.0.5)
Web version is v6.0.1 (Latest: v6.0.2)
FTL version is v6.0.4 (Latest: v6.0.4)
root@chimaera:~#

Details about my system:
Pi-hole runs in a VM in my Linux Devuan box.

root@chimaera:~# uname -a
Linux chimaera 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
root@chimaera:~#

The log file says only this:

root@chimaera:~# cat /etc/pihole/install.log
  [✓] Installing scripts from /etc/.pihole

  [i] Installing configs from /etc/.pihole...

  [✓] Installing latest Cron script

  [i] Installing latest logrotate script...
	[i] Existing logrotate file found. No changes made.
  [✓] man pages installed and database updated
root@chimaera:~#

Pi-hole diagnostic says nothing.
I have uploaded the debug.log and the token is https://tricorder.pi-hole.net/vsCgiCtv/

Note: as I saw it generated an error, I disabled NTP on IPv6 / IPv4.

Please advise.

Best,

JHM

2

Do you get more insights when your run the update script more verbose

sudo bash -x /opt/pihole/update.sh

3

Hello:

... more insights when your run the update script more verbose
Hmm ...

Really can't say as bash -x /opt/pihole/update.sh probably fails (?) because (being Devuan Linux unsupported) upgrading requires the use of the PIHOLE_SKIP_OS_CHECK=true pihole -r stanza.

If you could send the the proper stanza to use in this case ie: to get the more verbose printout, I'll rapidly have a go at it and post/upload the result for you to see.
Or ...
Let me know if just editing /opt/pihole/update.sh like this will give me a usable verbose output:

--- snip ---
line 109
line 110     # Perform an OS check to ensure we're on an appropriate operating system
line 111     # os_check
line 112
--- snip ---

Thanks for your input.

Best,

JHM
4

Try

sudo PIHOLE_SKIP_OS_CHECK=true bash -x /opt/pihole/update.sh

5

Hello:

Try PIHOLE_SKIP_OS_CHECK=true bash -x /opt/pihole/update.sh.

That worked. 8^D

--- snip ---
 [✓] Done.

  [i] The install log is located at: /etc/pihole/install.log
  [✓] Update complete! 

Core version is v6.0.5 (Latest: v6.0.5)
Web version is v6.0.2 (Latest: v6.0.2)
FTL version is v6.0.4 (Latest: v6.0.4)
+ exit 1
root@chimaera:~#

Early this morning while doing some research, I came across this post.

On modern Debian/Ubuntu-based Linux systems, you'll also have to add an AppArmor exception for this new file so unbound can write into it.

I do not like or run apparmor in any of my boxes and the VM where pi-hole runs is no exception, so it is disabled at boot in the kernel command line by adding security=none and apparmor=0.

But although service --status-all reported [ - ] apparmor ie: not running, something was keeping the installer from working properly but the log was not reporting it, at least as far as my limited knowledge would alIow me to see.

So, on a whim, I purged apparmor and deleted all its residual configuration files.
That was before I got to read your post and ran your new stanza which, as reported above, worked as expected.

Maybe the pi-hole installer/updater checks to see if the apparmor service is installed instead of checking that it is actually running?

It is either that or maybe apparmor runs whether the system's admin/owner wants it to or not.

If that is the case, it does not bode well for the Linux ecosystem.
What next then?

Edit:
You may want to consider making the installer/updater print out a warning when and if (for whatever reason) it cannot write to any file it needs to write to and point to the post I have linked to, with a specific reference to apparmor if it turns out it is the only cause for this problem.

That said, please note that this had never happened before upgrading to v6.0.5.

Let me know if you need the debug installer printout and how I can upload it for you to check it out.

Thank you very much for your input.
Much appreciated.

Best,

JHM

6

Hello:

Maybe the `pi-hole` installer/updater checks to see if the `apparmor` service is installed instead of checking that it is actually running?
... or maybe `apparmor` runs whether the system's admin/owner wants it to or not.

@yubiuser
Would you have any insight on this?

Completely uninstalling/purging everything apparmor from the sytem allowed the Pi-hole update to complete and the problem was solved.

But apparmor (to my knowledge) was not running.
ie: security=none and apparmor=0 had been added to the kernel command line.

And the Pi-hole logs did not report not being able to write to /var/log/syslog* even though the Pi-hole upgrade was carried out by root.

  • this because I never set a specific log file for unbound:
server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"
verbosity: 0
--- snip ---

I guess that the Pi-hole updater was wanting to write to /var/syslog and not being able to do so, did not complete the installation properly.

I'd appreciate your comments on this matter.

Best,

JHM

7

That's a pity, as that new stanza wasn't intended to fix anything, but rather to improve debugging by auditing every script line on execution, which potentially would have allowed us to pinpoint your issue.

What Devuan release are you running on your Pi-hole machine?

8

Hello:

... that new stanza wasn't intended to fix anything ...

Yes, I was aware of that.
I do have the log, albeit post apparmor purge.

... potentially would have allowed us to pinpoint your issue.

Issue which ceased to exist once everything apparmor was purged from my system.
Nothing else was changed, edited or modified.

What Devuan release ...

Devuan Chimaera.

~$ uname -a
Linux chimaera 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
~$

Like I mentioned, I had never had a Pi-hole upgrade problem before.
Everything was smooth and straightforward using PIHOLE_SKIP_OS_CHECK=true pihole -r.

Edit:
What worries me is what may have happened.
ie: that apparmor (apparently disabled) was actually enabled and working, meaning that apparmor=0 has no effect.

Hence the question in my previous post (09/03) with regards to how the Pi-hole installer/updater works.

Thanks for the prompt reply.

Best,

A.

9

We are not checking anything related to apparmor during installation or update.

The installer is located here:

10

Hello:

I see.

So ...
Do you have any idea as to what could have caused the upgrade to 6.0.5 to fail?

I take it that you saw nothing of relevance in the debug.log I uploaded which makes me think that there is no bug in the Pi-Hole installer.

Thank you for your help.

Best,

JHM

11

No idea to be honest. The debug log was fine and obviously no error was reported during the update. It simply didn't work. Let's see if it works fine the next time.

12

Hello:

Quite so.

A question if i may:

Hypothetically speaking, if apparmor had been running (ie: security=none and apparmor=0 not added to the kernel command line) and as a result the installer was not allowed to write to /var/log/syslog, would the reported failure have happened?

Unless I am mistaken, an indication of apparmor being suspect in all this is the fact that the installer runs as root and that after purging its residual configuration files, the updater was able to complete the installation.

Best,

JHM

13

No, FTL would have probably warned, but the upgrade should not have been affected.

14

Hello:

Right.

Thank you very much for your efforts and (obviously) for Pi-hole.

Best,

JHM