I just updated my secondary Pihole node, and it is no longer resolving. I cannot access the admin page in the browser. I was already updated to v6 and everything was working fine. I was running Core v6.0.3 and the update took it to v6.0.4
if you ssh into the pi and run sudo ss -tupln |grep -i pihole you can verify if the webserver is listening on the expected port.
Looks like the update changed the ports again. Same thing happened after going from v5 to v6, the installer did not ask if I wanted to disable lighthttpd, so I had to disable it manually. As such the 80 & 443 ports were in use so it listened on alternate ports. This update appears to have changed the ports to alternates even though lighthttpd is not running.
Came here to also report this
https://tricorder.pi-hole.net/oxTlil5q/
I tried remedies suggested:
sudo ss -tupln |grep -i pihole
But to no avail. It looks like this issue is widespread. Is there a way to walk-back the update? Unless I disable PiHole blocking my router doesn't operate properly. Thanks.
I updated the webserver port settings in pihole.toml to match the settings on my primary node. Then rebooted the pi and now the web server is not listening at all.
Primary Node pihole.toml
webserver.port = "80o,[::]:80o,443so,[::]:443so" ### CHANGED, default = "80o,443os,[::]:80o,[::]:443os"
sudo ss -tupln |grep -i pihole
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=78863,fd=20))
udp UNCONN 0 0 0.0.0.0:123 0.0.0.0:* users:(("pihole-FTL",pid=78863,fd=40))
udp UNCONN 0 0 :53 : users:(("pihole-FTL",pid=78863,fd=22))
udp UNCONN 0 0 :123 : users:(("pihole-FTL",pid=78863,fd=42))
tcp LISTEN 0 200 0.0.0.0:443 0.0.0.0: users:(("pihole-FTL",pid=78863,fd=37))
tcp LISTEN 0 200 0.0.0.0:80 0.0.0.0: users:(("pihole-FTL",pid=78863,fd=35))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=78863,fd=21))
tcp LISTEN 0 200 [::]:443 [::]:* users:(("pihole-FTL",pid=78863,fd=38))
tcp LISTEN 0 200 [::]:80 [::]:* users:(("pihole-FTL",pid=78863,fd=36))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=78863,fd=23))
That node has not been updated and is working fine.
Secondary Node pihole.toml
webserver.port = "80o,[::]80o,443so,[::]:443so" ### CHANGED, default = "80o,443os,[::]:80o,[::]:443os"
sudo ss -tupln |grep -i pihole
udp UNCONN 0 0 0.0.0.0:53 0.0.0.0:* users:(("pihole-FTL",pid=769,fd=20))
udp UNCONN 0 0 :53 : users:(("pihole-FTL",pid=769,fd=22))
tcp LISTEN 0 32 0.0.0.0:53 0.0.0.0: users:(("pihole-FTL",pid=769,fd=21))
tcp LISTEN 0 32 [::]:53 [::]:* users:(("pihole-FTL",pid=769,fd=23))
I have rebooted my secondary node multiple times, the webserver is not listening. And my internal DNS entries are not resolving on that node. External DNS resolution seems to work most of time, but it also does fail occasionally.
I was missing a : in my port string. I am now in my admin site, but what I am seeing is confusing me. My local DNS list appears to have reverted to pre v6.
After my nebula-sync ran it corrected my local DNS list. Before I update my primary node I will need to change my nebula-sync to treat secondary as primary so I don't lose all my local dns settings.
As a note while I was previously unable to access the Admin portal my nebula-sync process was also failing. I assume the API is dependent on the web server, and since it was not running correctly the API was not available either.
Before you update the secondary node, if you haven't already, please move /etc/pihole/setupVars.conf somewhere else. If it exists then then now-fixed migration code will pick it up and pull in your v5 settings.
I'm truly sorry you got caught by this, rest assured I'm not sleeping very well currently!!
1 Like
I have not performed the update on the other node. Figured I would wait and see if someone replied.
Sorry - been running around putting out (small - I think) fires.
Here is the part of the install script that decides if it will carry out the migration:
What should have happened on the initial v6 upgrade is that setupVars.conf would have been migrated and then moved to another directory so that subsequent runs did not re-import the settings.
What actually happened was that we were checking for the existence of pihole.toml instead. There were some cases (but not all) where pihole.toml would get generated before it should have - causing the migration code to be skipped over entirely. This is what happened on your own install.
Now with the 6.0.4 hotfix, it is fixed to be the way it should always have been - which means it will run the migrations it should have run in the first place.
Subsequent updates will not cause this issue. I have a VM that I have snapshotted at V5, and one at 6.0.4. Before we get anywhere near releasing more updates to the install script - I will be running it several times against each to ensure configs are no longer overwritten/borked.
Ok I moved the setupVars.conf file to my user home dir. To be safe I disabled nebula-sync as well and then ran pihole -up on my main node. Everything appears to have worked wonderfully. I very much appreciate you. And as a developer myself I certainly understand the insanity that you all must be going through right now. Hopefully you can get some rest soon.
Thank you - it means a lot, truly. There have been some pretty unconstructive conversations in the last couple of days.
Ideally I'd invent a time machine right now, but I guess all we can do is move foward and get better 
Now that you mentioned the above I think I understand why when I upgraded from v5 to v6 that my local DNS list got wiped out. Fortunately for me my local DNS list had like 10 things in it, and they were all old so it wasn't a big deal.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.