Cold boot on Raspberry Pi running Pi-Hole in docker has issue with admin page

Expected Behaviour:

Doing a cold boot of my Raspberry Pi 3B model running Pi-Hole in a docker container it should load the admin dashboard. Currently not getting any charts or other data on the admin page. I have to shutdown the docker container and restart it and then everything seems to work.

  • Current OS
    Distributor ID: Raspbian
    Description: Raspbian GNU/Linux 10 (buster)
    Release: 10
    Codename: buster
  • Kernel
    5.10.11-v7+
  • Model
    Raspberry Pi 3 Model B Rev 1.2

Actual Behaviour:

This is what I am seeing on the dashboard after the cold boot:

Debug Token:

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

After a container restart everything looks fine:

Not sure if I read you correctly.

You say you are seeing your Pi-hole's dashboard not being populated from long term data for the last 24 hours after your reboot your Docker Pi-hole's host machine?
And a manual container restart will put that straight?

Would that perhaps involve two different Docker commands?

Yes, if I do a boot of the Raspberry Pi the dashboard has no long term data for the last 24 hours displayed on the admin dashboard. After a boot I then do a container down and a container up and then the data does appear. After the boot and verified the dashboard issues I issued:

docker-compose down

Wait for the container to stop, then do the:

docker compose up -d

again and then all the data is there.

An alternative is to issue a container restart via Portainer.

I think we can close this. The problem seems to be with the buster startup and when you have a Real Time Clock. The buster script that enables the time, in one of the last updates, removed the edit that would let the kernel grab the time from the RTC and at startup the time is incorrect. Time isn't updated in this state until the NTP server starts and it syncs with the network.

I added the edit back into the:

/lib/udev/hwclock-set

This forced the exit before the HWclock could be called to set the Pi's clock and just re-commented out:

if [ -e /run/systemd/system ] ; then
    exit 0
fi
1 Like

Since that's an RTC on an RPi: Did you disable fake-hwclock?
I think that may interfere in the way you've described if left active.

sudo systemctl stop fake-hwclock.service
sudo systemctl disable fake-hwclock.service

Yep Fake-hwclock has been disabled for two years, this Pi not only is my secondary DNS server it's also TimeServer with RTC. Used to be a Stratrum 0 device when I had a GPS receiver on it .

This happened after the Buster update. I can tell because the script I changed to use the RTC was back to the default version. I think there is a bunch of articles of setting up the RTC on PI's I just did a search and they called out the same edit to the exit condition in that script in addition to disabling the Fake-hwclock. I was using my documentation of the changes back when it a Stretch and now Buster since I had a lot of free time in December during the holidays, never had a more easier time upgrading in place with Linux.

I rarely did boots and my network and devices have been running for over 6 months since my last major infrastructure changes. But a UPS malfunction this weekend killed all my power and that is when I noticed the issue with Pi.Hole and the admin interface after the boot. After reading into the syslog and the events recorded they all had date/timestamp issues where the RTC should have provided the kernel the date/time. That lead me to crack open my documentation and review the kernel modules, NTP server, and fake-hwclock settings.

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