piHole fails to update on Ubuntu 18.04 LTS, says "unsupported os"

Help
1

Hello all,

pihole -up fails to upgrade on my Ubuntu 18.04 LTS server. I found a thread discussing the issue, and someone mentioned it was a dig error, they asked for some dig commands to be ran, I've done so here;

dig +short -t txt versions.pi-hole.net
"Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"
pe or paste code here

 dig +noall +answer -t txt versions.pi-hole.net
versions.pi-hole.net.   39      IN      TXT     "Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"

dig +short +nocomments -t txt versions.pi-hole.net
"Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"

dig +short +nocookie -t txt versions.pi-hole.net
"Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"

The other thread mentioned a "bad" dns server, looked like some Microsoft dns server, the guy removed it I guess and it fixed it. Problem is, my upstream DNS is my firewall. There was one more command they ran to get to that;

dig -t txt versions.pi-hole.net

; <<>> DiG 9.11.3-1ubuntu1.12-Ubuntu <<>> -t txt versions.pi-hole.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56222
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;versions.pi-hole.net.          IN      TXT

;; ANSWER SECTION:
versions.pi-hole.net.   22      IN      TXT     "Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 20 00:24:58 EDT 2020
;; MSG SIZE  rcvd: 127

not sure why it's the loopback? Anyways, in piHole, my upstream dns is set to Custom, and going to my firewall at 192.168.1.1#853

DNS is blocked on the firewall, to prevent leaking. As I want everyone on my network to go through my pihole.

Thanks for the help

2

Did you read below section when creating this thread ?

#### Please follow the below template, it will help us to help you!

### *If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using `nginx` instead of `lighttpd`, or there is some other aspect of your install that is customised) - please use the [Community Help](https://discourse.pi-hole.net/c/bugs-problems-issues/community-help/36) category.*

## Expected Behaviour:
_[Replace this text with what you think should be happening. Please include as much detail as possible including, but not limited to:
 -operating system
-hardware]_

## Actual Behaviour:
_[replace this text with what is actually happening]_

## Debug Token:
_[Replace this text with the debug token provided from running `pihole -d` (or running the debug script through the web interface]_
3

I did. But considering the amount of detail I needed to include, the 'template' didn't really fit. I wanted to include as much detail as possible.

As far as the thread I previously mentioned, it was posted here;

He did not follow the 'template' either ...So not sure what I'm missing here.

Thanks
wangel

4

The last line states:

## Debug Token:
_[Replace this text with the debug token provided from running `pihole -d` (or running the debug script through the web interface]_

It will help the mods/devs to have a better understanding.

5

Understood, my apologies because pihole wasn't actually crashing, I didn't think it would generate a debug token or it would have provided any useful information.

After running it though, I see it collected a ton of info, and that I should have included that to begin with.

https://tricorder.pi-hole.net/j0susuxq15

Hopefully that sheds more light on the issue and gives more detail than what I posted above.

Thank you

1 Like
6 
pi@noads:~ $ dhcpcd --dumplease eth0
[..]
domain_name_servers='127.0.0.1'

pi@noads:~ $ tail /etc/dhcpcd.conf
[..]
interface eth0
  static ip_address=10.0.0.2/24
  static routers=10.0.0.1
  static domain_name_servers=127.0.0.1

Could you post full output for the pihole -up command (might want to redact some) ?

7

Here's pihole -up

 pihole -up
[sudo] password for xxxxxx:
  [i] Checking for updates...
  [i] Pi-hole Core:     up to date
  [i] Web Interface:    up to date
  [i] FTL:              update available

  [i] FTL out of date, it will be updated by the installer.

  [✓] Root user check

        .;;,.
        .ccccc:,.
         :cccclll:.      ..,,
          :ccccclll.   ;ooodc
           'ccll:;ll .oooodc
             .;cll.;;looo:.
                 .. ','.
                .',,,,,,'.
              .',,,,,,,,,,.
            .',,,,,,,,,,,,....
          ....''',,,,,,,'.......
        .........  ....  .........
        ..........      ..........
        ..........      ..........
        .........  ....  .........
          ........,,,,,,,'......
            ....',,,,,,,,,,,,.
               .',,,,,,,,,'.
                .',,,,,,'.
                  ..'''.

  [✓] Update local cache of available packages
  [i] Existing PHP installation detected : PHP version 7.2.24-0ubuntu0.18.04.6
  [i] Performing unattended setup, no whiptail dialogs will be displayed
  [✓] Disk space check

  [✓] Checking apt-get for upgraded packages... up to date!

  [i] Installer Dependency checks...
  [✓] Checking for dhcpcd5
  [✓] Checking for git
  [✓] Checking for iproute2
  [✓] Checking for whiptail
  [✓] Checking for dnsutils

  [✗] Unsupported OS detected: Ubuntu 18.04.5 LTS
      https://docs.pi-hole.net/main/prerequesites/#supported-operating-systems

      e.g: If you are seeing this message on a fresh install, you can run:
             'curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash'

           If you are seeing this message after having run pihole -up:
             'PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r'
           (In this case, your previous run of pihole -up will have already updated the local repository)

      If that is the case, you can feel free to ask the community on Discourse with the Community Help category:
      https://discourse.pi-hole.net/c/bugs-problems-issues/community-help/

  Unable to complete update, please contact Pi-hole Support

piHole is not my dhcp server, my firewall hands out dhcp. That said, pihole has a static map for it's mac on my dhcp server.

Thank you

8

dhcpcd is just a network manager:

pi@noads:~ $ apt show dhcpcd5
[..]
Description: DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
 dhcpcd is a one stop network management daemon which includes
  * RFC compliant DHCPv4 and DHCPv6 clients
  * DHCPv6 Prefix Delegation support
  * IPv4LL (aka ZeroConf) support
  * ARP address conflict resolution
  * Link carrier detection
  * Wireless SSID profiles
  * ARP ping profiles

I cant see anything wrong directly.
Wait for a mod/dev or someone else that knows.

9

I figured out the problem. In the update script, there's this line;

 IFS=" " read -r -a supportedOS < <(dig +short -t txt ${remote_os_domain} @ns1.pi-hole.net | tr -d '"')

Which, uses dig to ask for the txt record from ns1.pi-hole.net

Problem is, I have all outbound dns requests to anything other than my internal dns server blocked. So that was failing everytime.

I removed @ ns1.pi-hole.net and reran my update, and it worked just fine.

I at least band-aided my problem. I could have allowed pihole access to external dns servers also .. and maybe that's what I should have done in the mean time ... but next time I go to do an update, if the script is replaced, I'll have to allow pihole external dns or remove the line again.

For any dev/moderator or anyone that see's this, my network configuration is;

Clients -> PiHole -> pFsense -> 1.1.1.1 ... everything is on port 853, minus the clients request to piHole to begin with.

Thanks

1 Like
10

The server was added after some users reported problems with faulty Microsoft DNS servers you mentioned above. The drawback is, that advanced users like you, which block outbound p53 will encounter the issue. The team juged it might be a faire trade off as advanced users can/should/will find out what and why it went wrong and can fix the issue.

Add

The installer/updater will be further improved to make it clearer if the check for supported OS failes due to dig failure. That should improve troubleshooting.

2 Likes
13

It's fairly simple to eliminate the trade off, using the following code:

resolversArray=( ns1.pi-hole.net 127.0.0.1)
for (( i=0; i<${#resolversArray[@]}; i++ )); do
	IFS=" " read -r -a supportedOS < <(dig +short -t txt ${remote_os_domain} @${resolversArray[i]} | tr -d '"')
	if [ ! ${#supportedOS[@]} -eq 0 ]; then
		break
	fi
done

As opposed to editing the script, you could add a line to your hosts file

127.0.0.1 ns1.pihole.net

Just some suggestions, there might be even better ways to do this.

15

There will be some tweaks in the next version that seek to clarify the output in case of this check failing:

https://github.com/pi-hole/pi-hole/pull/3702

I've never actually played with blocking outbound 53 (with exceptions) on my network. To me a more sensible solution would be to redirect outbound 53 (with the exception of that from pi-hole device) to the pi-hole device, to force all clients to resolve via pi-hole, rather than outright blocking outbound requests. If one was going to do anything at all.

17

Yep. Granted .. both solutions offered by you and jpgpi250 are both acceptable and would work just fine.

I opted for the drop a hand grenade on it to fix it method :smiley:

18

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.