Temp is populated.
4 tiles across the top are populated.
The graphs are populated.
Temp is not populated
4 tiles across the top are not populated
The graphs are displayed and updated as expected.
This in where it gets weird, this is local (on the pi) using the IP
Including an ifconfig because of what I saw in the debug about eth0
If you open the browser's development tools (press F12) and there specifically the Console, does it show any errors? How does the output compare when trying to access it via the different addresses?
So remote, 192.168.7.8/admin vs pi.hole/admin seem to be the same:
edit: The following is about this first post (until the separation line). For the second post, the relevant info is blow this line.
All those are not related to Pi-hole but some Mozilla telemetry you enabled (or which are enabled in your browser by default). I have no clue how they can be responsible for this. If failing to send telemetry prevents web content from being rendered ... this would be really ugly behavior.
Try disabling it first, I found this guide (scroll down to How to Disable Firefox Telemetry Collection):
Concerning your second post: This makes more sense. Please try the Network tab of the Developer Tools to see if there are some files that cannot be downloaded. This error looks like your browser failed to download a dependent script file from your Pi-hole (one that is responsible for filling in the content, actually).
If I put in the IP like here, the error reports the IP address
If I use pi.hole the errors are replicated in kind using that URL instead of the IP, naturally
The Learn More link is https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Not_defined
I turned off Predictable Network Interface Names to bring eth0 into the picture and created a new debug.
This did not seem to change anything other than the entry in the debug report abot eth0 not being availalbe.
(Seems like I've been compiling this while you were already experimenting with predictive interface names...)
There is a mismatch between the network interface name you've configured Pi-hole to use (eth0) and the name that your machine is actually using (enxb827ebe5e469).
As a result, Pi-hole isn't aware of your network connection:
*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the eth0 interface.
According to the debug log, you are running Raspberry Pi OS, hence it seems sort of strange that your system would use a mix of classical (wlan0) and so called predictive (enxb827ebe5e469) interface names.
You may want to revisit the respective configuration option for your RPi by running:
sudo raspi-config
and choosing 6 - Advanced Options and then A4 - Network Interface Names.
Once done, you should make Pi-hole aware of your choice by running
pihole -r
with Reconfigure.
Please report back whether that would fix your issue.
Aleady did that, please review new debug listed above.
I am beginning to think that this is specific to a browser.
When I am "local" to the PiHole I am on the RasPi using the native Chromium.
The IP 192.168.7.8/admin works, but 127.0.0.1/admin and/pi.hole/admin does not.
Up to this point when I said I was "remote" but on the local network I was on my MacBookPro and FireFox.
ATM I am on an Ubuntu Machine and Firefox and every address (IP and pi.hole) works without issue.
ATP I am very confused, but researching.
Thank you very much for your time and suggestions thus far, but this is looking like weirdness within each browser quite honestly.
Since you suspect it's related to Chromium:
Did you verify that DoH (DNS-over-HTTPS) is disabled?
It wouldn't fully explain the behaviour you are seeing, but it would allow your browser to bypass Pi-hole if it would be enabled (and thus would fail to resolve pi.hole), so it's worth checking anyway.
I am definitely not using DoH on any of my browsers.
And that wouldn't explain why the single Chromium Browser on the Pi itself acts differently among the different addresses:
192.168.7.8/admin (success)
pi.hole/admin (fail)
127.0.0.1/admin (fail)
Moreover, my personal daily driver (MacBookPro) fails all around.
My work daily driver (Windows) fails all around.
My hobby daily driver (Ubuntu) succeeds at IP and pi.hole
All the same version of FireFox/Chrome/Edge.
It's very perplexing. And it just started happening spontaneously.
I am unaware of any updates or config changes that happened (except probably browser updates, nothing infrastructure-wise; e.g. Pi-OS or PiHole).
I truly do not understand this behavior.
Does that mean it seems client-specific rather than browser-specific then?
As a side note, you may indeed use client-specific groups to pool lists by certain subjects when they are designed to facilitate client-specific blocking.
You have defined five groups
*** [ DIAGNOSING ]: Groups
id enabled name
---- ------- --------------
0 1 Default
1 1 Advertizing
2 1 Malicious
3 1 Tracking
4 1 Suspicious
But all of your clients use the Default group only.
This wouldn't be related to your issue, but you may be using less blocklists than you intend to.
Just a guess:
Some software running on both your MacBook and Windows, but not on Ubuntu?
Antivirus, perhaps?
No anti virus on Mac, and no anti virus on the Pi.
The Pi gets both behaviors in the same browser.
Chromium Browser on the Pi itself acts differently among the different addresses:
192.168.7.8/admin (success)
pi.hole/admin (fail)
127.0.0.1/admin (fail)
Can't explain that.
It appears the Pi is not using Pi-hole for its name server. Only Pi-hole can resolve the domain name pihole.
Check /etc/resolv.conf on the Pi and see which name server it is using.