Pihole Dashboard Partially loading and unusable

Help
1

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 category.

Expected Behaviour:

Dashboard loads as expected

Actual Behaviour:

image
image1170×2532 152 KB
image
image1170×2532 167 KB

Multiple devices
Multiple browsers
Incognito or not
Unlock origin disabled or not
Still occurs after a pihole repair

Debug Token:

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

2

First, get rid of the 69 lists, that will negate the need for 4893 white/black listings.

Then fix your network:

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
   192.168.1.240/24 does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)
   192.168.2.2/24 matches the IP found in /etc/pihole/setupVars.conf

[✓] IPv6 address(es) bound to the eth0 interface:
   fe80::9488:7266:478e:3afb does not match the IP found in /etc/pihole/setupVars.conf (https://discourse.pi-hole.net/t/use-ipv6-ula-addresses-for-pi-hole/2127)

   ^ Please note that you may have more than one IP address listed.
   As long as one of them is green, and it matches what is in /etc/pihole/setupVars.conf, there is no need for concern.

   The link to the FAQ is for an issue that sometimes occurs when the IPv6 address changes, which is why we check for it.

Once you're on a sane configuration then see if the problem still exists.

5

Large number of entries are expected, ~4.1k blacklist entries for MassMove

Anyway the lists aren't the issue I can say that, using the same/sync'd gravity DB on a different instances.

Stupid question on the networking, but given the inaccessible UI, what's the right route to fix that?

6

Google for how to change IP address in Ubuntu.

7

....perhaps misunderstood what you're saying then.

The pi is active and working just fine other than the dashboard (on 192.168.2.2)

I don't follow how or why the the ip4 needs to be changed as it's working fine and is actively in use for DNS; again it's just the dashboard acting up

I don't follow why I'd need to change the server ip when it's working?

8

The interface (eth0) has two IP addresses. 192.168.2.2 and 192.168.1.240

You also have two DHCP servers, it seems:

*** [ DIAGNOSING ]: Discovering active DHCP servers (takes 10 seconds)
   Scanning all your interfaces for DHCP servers
   Timeout: 10 seconds
   
   * Received 300 bytes from eth0:192.168.2.1
     Offered IP address: 192.168.2.2
     Server IP address: 192.168.2.1
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.2.1
      lease-time: 86400 ( 1d )
      renewal-time: 43200 ( 12h )
      rebinding-time: 75600 ( 21h )
      netmask: 255.255.255.0
      broadcast: 192.168.2.255
      domain-name: "local"
      dns-server: 192.168.2.2
      router: 192.168.2.1
      --- end of options ---
    
   * Received 300 bytes from eth0:192.168.1.1
     Offered IP address: 192.168.1.241
     Server IP address: 192.168.1.1
     Relay-agent IP address: N/A
     BOOTP server: (empty)
     BOOTP file: (empty)
     DHCP options:
      Message type: DHCPOFFER (2)
      server-identifier: 192.168.1.1
      lease-time: 86400 ( 1d )
      renewal-time: 43200 ( 12h )
      rebinding-time: 75600 ( 21h )
      netmask: 255.255.255.0
      broadcast: 192.168.1.255
      dns-server: 192.168.1.1
      wpad-server: <cntrl sequence> (length 1)
      router: 192.168.1.1
      --- end of options ---
    
   DHCP packets received on interface lo: 0
   DHCP packets received on interface wlan0: 0
   DHCP packets received on interface eth0: 2

Can we get a debug token from this other instance, please?

Edit: not saying that is the cause of the issue - but that sticks out as odd for me. Could be causing issues with the web interface.

Another place to check - developer console of your web browser. Look for any errors in the console or network tabs, specifically scripts not loading. From the screenshots it looks as though the CSS is unable to load...

9

Updated fresh debug for the instance (remote from main / local to parents) with the broken UI is 2e55heu5qk

Dev Console shows no errors
Networking shows 200s (OK) or 304 (not modified) if cached for the network calls (cs and js)
js is not blocked

Debug from the remote (my primary / my instance / remote from parents), working, second instance 53tfbbribc

10

Ah, hold on.

What if you access the web interface of the main one by http://192.168.2.2/admin? (instead of pi.hole)

(Just a hunch - Something gives me the impression that the device you are connecting from is getting confused as to the actual IP address of pi.hole)

edit: it seems like you have some non-trivial network setup happening, across two different subnets,

That it works on one and not the other suggests that this is a configuration issue rather than an issue with Pi-hole itself

11

same issue via the IP

I think I've accidentally made it sound more complicated than it is.
They're two distinct networks and the only relation is gravity sync.

192.168.1.X are at my house
192.168.2.X are at my parent's with the problematic pi

Only relation between the two subnets is remote gravity sync between the two

At this point going to try a pihole -r reinstall on the 192.168.2 pi as repairs and multiple reboots have done nothing

12

Just for shits and giggles... Try the nuclear option on the web interface instead:

sudo rm -rf /var/www/html/admin
sudo git clone https://github.com/pi-hole/adminLTE /var/www/html/admin

I guess there is also the possibility of file system issues, too - I guess not so much an easy fix remotely.

1 Like
13

Well damn, was just gonna say a reinstall did not fix it (spoiler: it did not)

But nuclear option on webui seems to have did it.

Don't know why/how, but won't question it

Thanks!

15

It's possibly (but not definitely) indicative of a file system issue. If it were me, and it weren't too much hassle, I'd reflash the SD card and start again

16

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