The issue I am facing:
On one of my three servers (the other two are fine), I'm getting "Unsupported OS detected: Ubuntu 22.04" when I try to update to Pi-hole 5.17, FTL 5.23 & Web Interface 5.20/.1. This is when PIHOLE_SKIP_OS_CHECK=false, and making it =true doesn't bother to update any of the Pi-hole system.
Uh, what? Prerequisites - Pi-hole documentation clearly and specifically states that Ubuntu 22.04 is supported, and neither of my other servers running the same OS (of them, once is ARM64 & the other is x86_64 AMD, but running an Oracle version of the kernel), have this problem; both of them updated fine.
Details about my system:
The affected system is running in a Linode "nanode" (so, x86_64 AMD) with the generic kernel. Package repos are obviously hosted/filtered by Linode, but the three systems have functioned effectively identically with very minor tweaks for their individual use cases, since installing. I also run unbound for DNS, and serve wireguard on the same server, as well as ufw & fail2ban.
What I have changed since installing Pi-hole:
pihole-FTL.conf has gotten a DELAY_STARTUP=5 to deal with Pi-hole and wireguard daemons apparently sometimes stepping on each other's feet at boot time, and BLOCK_ICLOUD_PR=false, because Apple. RATE_LIMIT=1000/60 has automatically popped up in there, cuz (as for anyone who's run Pi-hole for a bit), some client exceeded at some point.
As far as Pi-hole's configuration by me, that's it on that server. I occasionally tweak how wireguard is configured, but there have been no changes to software in recent months except unattended-upgrades, and my own attended upgrades (but no apt installs or removes).
Please let me know of any other info that may help diagnosis, and thanks for your attention!
Please upload a debug log and post just the token URL that is generated after the log is uploaded by running the following command from the Pi-hole host terminal:
or do it through the Web interface:
Tools > Generate Debug Log
Thank you so much for the quick reply! Below is the link to the token URL. Anecdotally, it did pause for quite a while when determining the OS, so maybe Linode is doing something hinky with how the OS identifies itself? Anyway:
Same issue here using a Raspberry Pi 4.
Same issue on a Ubuntu Minimal install (Ubuntu 22.04.2 LTS (GNU/Linux 5.15.0-73-generic x86_64))
My individual issue is resolved by:
a) The fact that it would indeed update, it would just nag if it checked the OS, even after the update, and
b) I’ve just retired that server, and neither of my other ones ever had that problem.
Happy to keep this thread open for others with similar problems, but let me know, mods, if you’d like me to close.
Same issue with Ubuntu Server: Unsupported OS detected: Ubuntu 22.04
Your issue is IPv6 connectivity.
[✗] Distro: Ubuntu
[✓] dig return code: 0
[i] dig response: ;; communications error to 2600:9000:5301:9700::1#53: timed out
[✗] Error: Ubuntu is not a supported distro (https://docs.pi-hole.net/main/prerequisites/)
Your system is trying to use the IPv6 address for the nameserver but you don't have public IPv6 connectivity.
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] smetrics.staplesadvantage.com is :: on lo (::1)
[✓] smetrics.staplesadvantage.com is :: on enp1s0 (2600:REDACTED:b093)
[✗] Failed to resolve smetrics.staplesadvantage.com on enp1s0 (fe80::e654:e8ff:fe0c:b093)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
I see you have a Global Unicast Address set for the server but it doesn't appear to be working.
I don't know if you intended to delete your post but as a follow-up, I'm wondering if there should be a force IPv4 on that
dig check for the record. I'm going to assume that just about everyone is going to have at least IPv4 connectivity and not be running IPv6 as the sole protocol.
Or get really fancy and run both IPv4 and IPv6 protocol based
digs and if at least one succeeds then go with that.
I know there is some discontent with forcing the check to connect to
ns1.pi-hole.net but there was a reason for that requirement and I'm not quite to the point of acknowledging that the reason is no longer valid.
This could be the way to go as it would also catch the IPv6-only setups (not sure if there are a lot, but might increase in the future)
That was indeed the problem. Thanks!
Not sure what happened to my IPV6 - it had been working. https://test-ipv6.com/ slows failure now although it has worked previously. After disabling IPV6 completely I am able to update.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.