docker-pi-hole
docker-pi-hole copied to clipboard
pi-hole
2022.04.1 (Using image 334d46d0f4bd) not working on Raspbian Buster
For me 2022.04.1 (Using image 334d46d0f4bd) does not fix anything. I can produce this debug log when I revert to 036a3f19f8be https://tricorder.pi-hole.net/HxlHpPSE/ Note that I'm on armhf.
On docker host:
❯ uname -a
Linux raspberrypidocker 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux
Originally posted by @Mellbourn in https://github.com/pi-hole/docker-pi-hole/issues/1035#issuecomment-1086621033
Same behavior as before. Log ends with
pihole | [services.d] done.
pihole | sudo: unable to get time of day: Operation not permitted
pihole | sudo: error initializing audit plugin sudoers_audit
pihole | sudo: unable to get time of day: Operation not permitted
pihole | sudo: error initializing audit plugin sudoers_audit
[repeated]
opened a new issue as something is off in your debug log, and I think it is either a different issue or a misconfiguration:
[i] Core: v5.9 (https://discourse.pi-hole.net/t/how-do-i-update-pi-hole/249)
That should be showing v5.9.1
Just realised you said you reverted. I'm not able to match those digest hashes to anything on docker hub? Where are you getting that from?
What does your run command/compose file look like?
Also, what is the output of:
docker run -it --rm --name=pitest pihole/pihole:2022.04.1
currently working docker-compose:
services:
pihole:
container_name: pihole
image: pihole/pihole@sha256:60a9127372b0f7bb4b5eb09bc95e2735eb7b237999acf4bb079eb14b0f14632e
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp"
- "80:80/tcp"
- "443:443/tcp"
environment:
TZ: 'Europe/Stockholm'
WEBPASSWORD: 'not-my-real-password'
# this is still needed to get pi.hole to work
ServerIP: '192.168.211.11'
DNSSEC: 'true'
# this makes the name of the docker image not be a random hash. This name is recognized only in the docker host environment
hostname: 'pi-hole-in-docker'
# Volumes store your data between container upgrades
volumes:
- './pi-hole/etc-pihole/:/etc/pihole/'
- './pi-hole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
# these are supposedly needed, otherwise you will get 127.0.0.11 problems https://github.com/pi-hole/docker-pi-hole/issues/410#issuecomment-460515706 - still doesn't work
dns:
- 127.0.0.1
- 1.1.1.1
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN
restart: unless-stopped
The image line used to read
image: pihole/pihole:latest
❯ docker images pihole/pihole
REPOSITORY TAG IMAGE ID CREATED SIZE
pihole/pihole <none> 334d46d0f4bd 54 minutes ago 237MB
pihole/pihole <none> ac573d50f83a 13 hours ago 237MB
pihole/pihole latest 036a3f19f8be 6 weeks ago 232MB
pihole/pihole master-armhf-buster da805bf456b6 6 months ago 334MB
pihole/pihole master-armhf 25db6a93aa0e 20 months ago 301MB
pihole/pihole dev 65b1970d504f 2 years ago 324MB
(I moved the latest tag to get it to work earlier)
OK, that matches the IDs I have here, and using your above compose I get no issues loading it on an rpi 4 running bullseye.
pi@dockerpi:~/docker/playground $ uname -a
Linux dockerpi 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
pi@dockerpi:~/docker/playground $ docker --version
Docker version 20.10.14, build a224086
pi@dockerpi:~/docker/playground $ docker images pihole/pihole:latest
REPOSITORY TAG IMAGE ID CREATED SIZE
pihole/pihole latest 334d46d0f4bd About an hour ago 237MB
pi@dockerpi:~/docker/playground $ cat docker-compose.yml
version: '3.3'
services:
pihole:
container_name: piholetest
image: pihole/pihole:latest
ports:
- "53:53/tcp"
- "53:53/udp"
- "67:67/udp"
- "80:80/tcp"
- "443:443/tcp"
environment:
TZ: 'Europe/Stockholm'
WEBPASSWORD: 'not-my-real-password'
# this is still needed to get pi.hole to work
ServerIP: '192.168.211.11'
DNSSEC: 'true'
# this makes the name of the docker image not be a random hash. This name is recognized only in the docker host environment
hostname: 'pi-hole-in-docker'
# Volumes store your data between container upgrades
volumes:
- './pi-hole/etc-pihole/:/etc/pihole/'
- './pi-hole/etc-dnsmasq.d/:/etc/dnsmasq.d/'
# these are supposedly needed, otherwise you will get 127.0.0.11 problems https://github.com/pi-hole/docker-pi-hole/issues/410#issuecomment-460515706 - still doesn't work
dns:
- 127.0.0.1
- 1.1.1.1
# Recommended but not required (DHCP needs NET_ADMIN)
# https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
cap_add:
- NET_ADMIN
restart: unless-stopped
pi@dockerpi:~/docker/playground $ docker-compose up
Starting piholetest ... done
Attaching to piholetest
piholetest | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
piholetest | [s6-init] ensuring user provided files have correct perms...exited 0.
piholetest | [fix-attrs.d] applying ownership & permissions fixes...
piholetest | [fix-attrs.d] 01-resolver-resolv: applying...
piholetest | [fix-attrs.d] 01-resolver-resolv: exited 0.
piholetest | [fix-attrs.d] done.
piholetest | [cont-init.d] executing container initialization scripts...
piholetest | [cont-init.d] 05-changer-uid-gid.sh: executing...
piholetest | [cont-init.d] 05-changer-uid-gid.sh: exited 0.
piholetest | [cont-init.d] 20-start.sh: executing...
piholetest | ::: Starting docker specific checks & setup for docker pihole/pihole
piholetest |
piholetest | [i] Installing configs from /etc/.pihole...
piholetest | [i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
[✓] Installed /etc/dnsmasq.d/01-pihole.conf
[✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
piholetest | Existing DNS servers detected in setupVars.conf. Leaving them alone
piholetest | ::: Pre existing WEBPASSWORD found
piholetest | DNSMasq binding to default interface: eth0
piholetest | Added ENV to php:
piholetest | "TZ" => "Europe/Stockholm",
piholetest | "PIHOLE_DOCKER_TAG" => "2022.04.1",
piholetest | "PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
piholetest | "ServerIP" => "192.168.211.11",
piholetest | "CORS_HOSTS" => "",
piholetest | "VIRTUAL_HOST" => "192.168.211.11",
piholetest | Using IPv4 and IPv6
piholetest | ::: Preexisting ad list /etc/pihole/adlists.list detected ((exiting setup_blocklists early))
piholetest | https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
piholetest | ::: Testing lighttpd config: Syntax OK
piholetest | ::: All config checks passed, cleared for startup ...
piholetest | ::: Enabling Query Logging
piholetest | [i] Enabling logging...
[✓] Logging has been enabled!
piholetest | ::: Docker start setup complete
piholetest | Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
piholetest | Pi-hole version is v5.9.1 (Latest: v5.9.1)
piholetest | AdminLTE version is v5.11 (Latest: v5.11)
piholetest | FTL version is v5.14 (Latest: v5.14)
piholetest | Container tag is: 2022.04.1
piholetest | [cont-init.d] 20-start.sh: exited 0.
piholetest | [cont-init.d] done.
piholetest | [services.d] starting services
piholetest | Starting crond
piholetest | Starting lighttpd
piholetest | Starting pihole-FTL (no-daemon) as pihole
piholetest | [services.d] done.
Also, if I have correctly read your debug log - you are not using Pi-hole for DHCP, you can safely remove the port mapping for port 67 and also remove the cap_add section
I moved the tag back, and did a docker-compose down/up but it did not help
REPOSITORY TAG IMAGE ID CREATED SIZE
pihole/pihole latest 334d46d0f4bd About an hour ago 237MB
pihole/pihole <none> ac573d50f83a 13 hours ago 237MB
pihole/pihole <none> 036a3f19f8be 6 weeks ago 232MB
pihole/pihole master-armhf-buster da805bf456b6 6 months ago 334MB
pihole/pihole master-armhf 25db6a93aa0e 20 months ago 301MB
pihole/pihole dev 65b1970d504f 2 years ago 324MB```
❯ docker run -it --rm --name=pitest pihole/pihole:2022.04.1
Unable to find image 'pihole/pihole:2022.04.1' locally
2022.04.1: Pulling from pihole/pihole
Digest: sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea
Status: Downloaded newer image for pihole/pihole:2022.04.1
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-resolver-resolv: applying...
[fix-attrs.d] 01-resolver-resolv: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 05-changer-uid-gid.sh: executing...
[cont-init.d] 05-changer-uid-gid.sh: exited 0.
[cont-init.d] 20-start.sh: executing...
::: Starting docker specific checks & setup for docker pihole/pihole
Assigning random password: 6vVbdYe8
[i] Installing configs from /etc/.pihole...
[i] Existing dnsmasq.conf found... it is not a Pi-hole file, leaving alone!
[✓] Installed /etc/dnsmasq.d/01-pihole.conf
[✓] Installed /etc/dnsmasq.d/06-rfc6761.conf
Existing DNS servers detected in setupVars.conf. Leaving them alone
[✓] New password set
DNSMasq binding to default interface: eth0
Added ENV to php:
"TZ" => "",
"PIHOLE_DOCKER_TAG" => "2022.04.1",
"PHP_ERROR_LOG" => "/var/log/lighttpd/error.log",
"ServerIP" => "0.0.0.0",
"CORS_HOSTS" => "",
"VIRTUAL_HOST" => "0.0.0.0",
Using IPv4 and IPv6
::: setup_blocklists now setting default blocklists up:
::: TIP: Use a docker volume for /etc/pihole/adlists.list if you want to customize for first boot
::: Blocklists (/etc/pihole/adlists.list) now set to:
https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
::: Testing lighttpd config: Syntax OK
::: All config checks passed, cleared for startup ...
::: Enabling Query Logging
[i] Enabling logging...
[✓] Restarting DNS server
[✓] Logging has been enabled!
::: Docker start setup complete
Checking if custom gravity.db is set in /etc/pihole/pihole-FTL.conf
Pi-hole version is v5.9.1 (Latest: v5.9.1)
AdminLTE version is v5.11 (Latest: v5.11)
FTL version is v5.14 (Latest: v5.14)
Container tag is: 2022.04.1
[cont-init.d] 20-start.sh: exited 0.
[cont-init.d] done.
[services.d] starting services
Starting lighttpd
Starting pihole-FTL (no-daemon) as pihole
Starting crond
[services.d] done.
So looks like the image works on your hardware... what next? 🤔
What is the output of docker info? (not that I'm 100% I'll be able to understand!)
❯ docker info
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Docker Buildx (Docker Inc., v0.8.1-docker)
Server:
Containers: 3
Running: 3
Paused: 0
Stopped: 0
Images: 13
Server Version: 20.10.14
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: 3df54a852345ae127d1fa3092b95168e4a88e2f8
runc version: v1.0.3-0-gf46b6ba
init version: de40ad0
Security Options:
seccomp
Profile: default
Kernel Version: 5.10.103-v8+
Operating System: Raspbian GNU/Linux 10 (buster)
OSType: linux
Architecture: aarch64
CPUs: 4
Total Memory: 3.706GiB
Name: raspberrypi4docker
ID: GHLE:KSE6:UXZK:PQM4:KU3Q:MKCL:4F7B:XDYQ:4F75:YT57:2OYF:XW2X
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No memory limit support
WARNING: No swap limit support
WARNING: No kernel memory TCP limit support
WARNING: No oom kill disable support
I don't know if it's relevant, but there was an issue with the arm64 / aarch64 architectures a while back https://github.com/pi-hole/docker-pi-hole/issues/587#issuecomment-594251857 Is the fix applied to all architectures?
As a last ditch workaround, can you add DNSMASQ_USER: 'root' to your environment and see if that makes a difference, please?
A couple of other questions that come to mind:
- Are you seeing this issue because you are on aarch64?
- Are you seeing this issue because you are on buster (how painful would it be to upgrade to bullseye? Is there even an aarch64 bullseye raspbian image?)
I don't know if it's relevant, but there was an issue with the arm64 / aarch64 architectures a while back #587 (comment)
Possibly not - we have since switched to using buildx for the multiarch images rather than our homebrew method
Adding DNSMASQ_USER: 'root' to environment: made no difference.
Last I checked you couldn't do major upgrades on Raspbian, so going to bullseye would be a full reinstall of the OS, so that would be a hassle. I could do it I guess, but I don't have the time in the next few weeks.
Dug out a Pi3 from the back of a drawer. Going to try 64bit bullseye...
Seems to work fine with the same compose file outlined above.
I had to jump through some hoops and use compose v2 as installing docker-compose 1.x was not working via the normal method (installed Docker 20.10.14 via the convenience script) but I cannot see how that would affect things...
Comparing the image IDs / digests, things are different (double checked the created date on each as the CREATED column looked off)
64 bit pi 3:
pi@raspberrypi64:~ $ docker images pihole/pihole --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
pihole/pihole 2022.04.1 sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea 71625e6cc03b 2 hours ago 295MB
pihole/pihole latest sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea 71625e6cc03b 2 hours ago 295MB
pi@raspberrypi64:~ $ docker inspect -f '{{ .Created }}' pihole/pihole:latest
2022-04-02T11:04:59.160847745Z
And on my 32 bit Pi4:
pi@dockerpi:~/docker/playground $ docker images pihole/pihole --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
pihole/pihole 2022.04.1 sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea 334d46d0f4bd 3 hours ago 237MB
pihole/pihole latest sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea 334d46d0f4bd 3 hours ago 237MB
pi@dockerpi:~/docker/playground $ docker inspect -f '{{ .Created }}' pihole/pihole:latest
2022-04-02T11:04:59.161872753Z
What is the output of docker images pihole/pihole --digests on yours? I note your image IDs are actually the same as my 32 bit image ids.. which is probably where the problem is. Note the size differences between my two devices, too
AFAIK - 64 bit Raspbian is still in beta (at least, it definitely was when it was based on buster!!!) which could explain the oddities you are seeing, where others are reporting the issues are fixed. The beta has only just recently been opened to a wider audience according to this blog:
https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/
My suggestion for now is to try bullseye (either the 64 bit image or 32 bit, up to you - but if it doesn't work on the former, try the latter) and go from there... I'll hold this issue open until you can try this...
Just realised you said you reverted. I'm not able to match those digest hashes to anything on docker hub? Where are you getting that from?
Comparing the image IDs / digests, things are different (double checked the created date on each as the CREATED column looked off)
FYI you can use this to get the digest corresponding to dockerhub:
docker image inspect image:tag --format '{{json .RepoDigests}}'
❯ docker images pihole/pihole --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
pihole/pihole 2022.04.1 sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea 334d46d0f4bd 7 hours ago 237MB
pihole/pihole latest sha256:91fbceda5406e63ffdfb807324d48d42f0bee8041396fbfd581067af303424ea 334d46d0f4bd 7 hours ago 237MB
pihole/pihole <none> sha256:7ca50487539eb222c2e989ceba361e8b733bbd51ec8c01db56f7bd81b5ae370b ac573d50f83a 19 hours ago 237MB
pihole/pihole <none> sha256:60a9127372b0f7bb4b5eb09bc95e2735eb7b237999acf4bb079eb14b0f14632e 036a3f19f8be 6 weeks ago 232MB
pihole/pihole master-armhf-buster sha256:00d1ccf368231c70f27340c40ab7b102c2543082eeacf7bf6605da2ed08cba70 da805bf456b6 6 months ago 334MB
pihole/pihole master-armhf sha256:2544519d2b9bf58db553dd4299d2992d5f65ed4d0627f096f09aacadf8f48f5b 25db6a93aa0e 20 months ago 301MB
pihole/pihole dev sha256:3a4c8cc914b3e39ed9761bfdd51f8f947e4c75073493aa31d183a1be9f808b59 65b1970d504f 2 years ago 324MB
Working on a new image that should detect NET_ADMIN and prevent DHCP from being activated. Also will allow non-DHCP to run without NET_ADMIN.
Please check 2022.04.2beta when the image is pushed to the repositories. Should be within 10 minutes of now.
still getting
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
I'm not sure how we can proceed on that, we don't call sudo in any capacity in the image.
It looks like your system isn't allowing date to be called.
Since this is an issue that is unrelated to this thread, please open a new issue.
I found this thread by searching for sudo: unable to get time of day: Operation not permitted
https://github.com/pi-hole/docker-pi-hole/issues/1043#issuecomment-1086622885
pihole/pihole:2022.02.1 is working
Linux kellerpi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux
I Am
On Sat, 2 Apr 2022 at 22:33 Dan Schaper @.***> wrote:
Okay, are you using Raspbian 64bit Buster?
— Reply to this email directly, view it on GitHub https://github.com/pi-hole/docker-pi-hole/issues/1043#issuecomment-1086717853, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANT675756RIBOZFXNBOEGDVDCVKDANCNFSM5SK2NPTA . You are receiving this because you were mentioned.Message ID: @.***>
I have not tried 2022.04.2beta yet, will do that right away.
❯ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 3
Model name: Cortex-A72
Stepping: r0p3
CPU max MHz: 1500,0000
CPU min MHz: 600,0000
BogoMIPS: 270.00
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster
2022.04.2beta did not work, it still threw
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
2022.04.2beta did not work for me either:
pihole | [services.d] done.
pihole | [1965-09-06 01:17:33.000 519M] Using log file /var/log/pihole-FTL.log
pihole | [1970-01-01 01:00:00.000 519M] ########## FTL started on pi-hole-in-docker! ##########
pihole | [1965-09-13 16:06:40.000 519M] FTL branch: master
pihole | [1969-12-19 05:20:44.000 519M] FTL version: v5.14
pihole | [1969-12-19 05:20:44.000 519M] FTL commit: 52e6b95
pihole | [1969-12-19 05:20:44.000 519M] FTL date: 2022-02-12 19:58:34 +0000
pihole | [1969-12-19 05:20:44.000 519M] FTL user: pihole
pihole | [1969-12-19 05:20:44.000 519M] Compiled for armv7hf (compiled on CI) using arm-linux-gnueabihf-gcc (Debian 6.3.0-18) 6.3.0 20170516
pihole | [1969-12-19 05:19:04.000 519M] Creating mutex
pihole | [1969-12-19 05:18:28.000 519M] Creating mutex
pihole | [1970-05-03 01:39:29.-1184080 519M] Starting config file parsing (/etc/pihole/pihole-FTL.conf)
pihole | [1970-01-01 01:00:00.000 519M] SOCKET_LISTENING: only local
pihole | [1970-01-01 01:00:00.000 519M] AAAA_QUERY_ANALYSIS: Show AAAA queries
pihole | [1969-12-19 05:18:52.000 519M] MAXDBDAYS: max age for stored queries is 7 days
pihole | [1970-01-01 01:00:00.000 519M] RESOLVE_IPV6: Resolve IPv6 addresses
pihole | [1970-01-01 01:00:00.000 519M] RESOLVE_IPV4: Resolve IPv4 addresses
pihole | [1970-01-01 01:00:00.000 519M] DBINTERVAL: saving to DB file every minute
pihole | [1970-01-01 01:00:00.000 519M] DBFILE: Using /etc/pihole/pihole-FTL.db
pihole | [1970-01-01 01:00:00.000 519M] MAXLOGAGE: Importing up to 24.0 hours of log data
pihole | [1969-12-19 05:18:08.42587 519M] PRIVACYLEVEL: Set to 0
pihole | [1969-12-19 05:18:52.000 519M] IGNORE_LOCALHOST: Show queries from localhost
pihole | [1932-06-24 09:46:56.-134687 519M] BLOCKINGMODE: Null IPs for blocked domains
pihole | [1969-12-19 05:18:52.000 519M] ANALYZE_ONLY_A_AND_AAAA: Disabled. Analyzing all queries
pihole | [1970-01-01 01:00:00.000 519M] DBIMPORT: Importing history from database
pihole | [1970-01-01 01:00:00.000 519M] PIDFILE: Using /run/pihole-FTL.pid
pihole | [1970-01-01 01:00:00.000 519M] PORTFILE: Using /run/pihole-FTL.port
pihole | [1970-01-01 01:00:00.-135675 519M] SOCKETFILE: Using /run/pihole/FTL.sock
pihole | [1969-12-19 05:18:12.000 519M] SETUPVARSFILE: Using /etc/pihole/setupVars.conf
pihole | [1970-01-01 01:00:00.000 519M] MACVENDORDB: Using /etc/pihole/macvendor.db
pihole | [1969-12-19 05:18:12.000 519M] GRAVITYDB: Using /etc/pihole/gravity.db
pihole | [1970-01-01 01:00:13.000 519M] PARSE_ARP_CACHE: Active
pihole | [1969-12-19 05:18:52.000 519M] CNAME_DEEP_INSPECT: Active
pihole | [1970-01-01 01:00:00.000 519M] DELAY_STARTUP: No delay requested.
pihole | [1969-12-19 05:18:52.000 519M] BLOCK_ESNI: Enabled, blocking _esni.{blocked domain}
pihole | [1969-12-19 05:18:52.000 519M] NICE: Cannot change niceness to -10 (permission denied)
pihole | [1970-01-01 01:00:00.000 519M] MAXNETAGE: Removing IP addresses and host names from network table after 7 days
pihole | [1969-12-19 05:18:52.000 519M] NAMES_FROM_NETDB: Enabled, trying to get names from network database
pihole | [1970-01-01 01:00:00.000 519M] EDNS0_ECS: Overwrite client from ECS information
pihole | [1970-01-01 01:00:00.000 519M] REFRESH_HOSTNAMES: Periodically refreshing IPv4 names
pihole | [1970-01-01 01:00:00.000 519M] RATE_LIMIT: Rate-limiting client making more than 1000 queries in 60 seconds
pihole | [1970-01-01 01:00:00.000 519M] LOCAL_IPV4: Automatic interface-dependent detection of address
pihole | [1970-01-01 01:00:00.000 519M] LOCAL_IPV6: Automatic interface-dependent detection of address
pihole | [1969-12-19 05:18:52.000 519M] BLOCK_IPV4: Automatic interface-dependent detection of address
pihole | [1969-12-19 05:18:52.000 519M] BLOCK_IPV6: Automatic interface-dependent detection of address
pihole | [1970-01-07 20:50:24.-1107 519M] REPLY_ADDR4: Using IPv4 address 192.168.211.11 instead of automatically determined IP address
pihole | [1970-01-07 20:50:24.000 519M] SHOW_DNSSEC: Enabled, showing automatically generated DNSSEC queries
pihole | [1969-12-19 05:18:52.000 519M] MOZILLA_CANARY: Enabled
pihole | [1970-01-01 01:00:00.000 519M] PIHOLE_PTR: internal PTR generation enabled (pi.hole)
pihole | [1970-01-03 07:36:48.000 519M] ADDR2LINE: Enabled
pihole | [1970-01-01 01:00:00.000 519M] REPLY_WHEN_BUSY: Permit queries when the database is busy
pihole | [1969-12-19 05:18:52.000 519M] BLOCK_TTL: 2 seconds
pihole | [1969-12-19 05:18:52.000 519M] BLOCK_ICLOUD_PR: Enabled
pihole | sudo: unable to get time of day: Operation not permitted
pihole | sudo: error initializing audit plugin sudoers_audit
pihole | sudo: unable to get time of day: Operation not permitted
pihole | sudo: error initializing audit plugin sudoers_audit
pihole | sudo: unable to get time of day: Operation not permitted
If I remove this from my docker-compose.yml:
cap_add:
- NET_ADMIN
Then I get another error in the log:
pihole | [1970-01-01 01:00:00.000 517M] Finished config file parsing
pihole | [1971-04-16 10:50:16.000 517M] Database version is 12
pihole | [1969-12-11 04:22:36.000 517M] Resizing "FTL-strings" from 40960 to (81920 * 1) == 81920 (/dev/shm: 1.1MB used, 67.1MB total, FTL uses 1.1MB)
pihole | [1970-01-01 01:00:51.-1390062 517M] Imported 0 alias-clients
pihole | [1970-06-12 05:54:36.-142078 517M] Database successfully initialized
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 0
That error message is repeated very quickly, with some variations:
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 6
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 9
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 13
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 14
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 15
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 20
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 20
pihole | [1970-01-01 01:00:51.-140421 517M] DB warn: TIMESTAMP should be larger than 01/01/2017 but is 20
FYI:
❯ lscpu
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 3
Model name: Cortex-A72
Stepping: r0p3
CPU max MHz: 1500.0000
CPU min MHz: 600.0000
BogoMIPS: 108.00
Flags: fp asimd evtstrm crc32 cpuid
Can you run something simple like docker run -it --rm alpine sh -c "date" and see what the date is in dockerland?
Just to clarify, is that the system date or the date reported in the alpine docker container?
❯ docker run -it --rm alpine sh -c "date"
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
22b1e5a07a97: Pull complete
Digest: sha256:f22945d45ee2eb4dd463ed5a431d9f04fcd80ca768bb1acf898d91ce51f7bf04
Status: Downloaded newer image for alpine:latest
Sat Dec 26 21:57:20 UTC 2105
I am in Sweden, summertime, my local time right is 22:57
But not December 2105 ;)
I think this is something to do with docker itself, not exactly sure. But since it's happening in another image I don't think its specific to our image.
And one more check please:
docker run -it --rm alpine sh -c "date -s 2022-04-02"
❯ docker run -it --rm alpine sh -c "date -s 2022-04-02"
date: can't set date: Operation not permitted
Sat Apr 2 00:00:00 UTC 2022
Okay, I really think this is down to the docker engine. Is there any way to use Bullseye to see if it is fixed there?
I have a Pi4 with Raspbian Buster 32bit and I get the same results for Alpine that you do. I'll try to image to the Bullseye release and see if I get the same response.
Unfortunately, I don't have time to upgrade to Bullseye now. I will have time in a couple of weeks.
I wanted to upgrade to bullseye anyway, maybe I can do it tomorrow or at the beginning of the next week. I will report when done. Thanx for your work and support!
This may be a long shot but have you tried to mount the hosts localtime as a workaround?
volumes:
- /etc/localtime:/etc/localtime:ro
And remove the TZ environment variable.
I think a user suggested a workaround in issue 1042, but I haven't tested it to see if it works or is something that may break another piece of software.
But it does appear to be Buster. I've tried Bullseye and it all works okay.
So I have here largely the same problem and currently have no time to set up the entire OMV with all the stuff on bullseye again. I think that I also use 32bit OS. There are also other containers and services running on the Pi. If you can not fix this, I'll stay with pihole:2022.02.1 for now, so it currently runs without problems.
The plan is to migrate everything to an AMD architecture in the next weeks anyway, if I can manage that :D.
As said above, you could try the workaround suggested in https://github.com/pi-hole/docker-pi-hole/issues/1042.
We still suggest an upgrade to bullseye as the safest path, but you can try the workaround at your own risk.
I suggest a full backup before any attempt (even before a bullseye upgrade). Even lower risk upgrades can cause unexpected results.
This may be a long shot but have you tried to mount the hosts localtime as a workaround?
volumes: - /etc/localtime:/etc/localtime:roAnd remove the
TZenvironment variable.
Tryed, didn't fix..currently on Buster armv7.
Hi,
I'm unable to run both 2022.04.1 and 2022.04.2beta given the same error above but on 32bit OS:
sudo: unable to get time of day: Operation not permitted
sudo: error initializing audit plugin sudoers_audit
while:
$ docker run -it --rm alpine sh -c "date"
Unable to find image 'alpine:latest' locally
latest: Pulling from library/alpine
22b1e5a07a97: Pull complete
Digest: sha256:f22945d45ee2eb4dd463ed5a431d9f04fcd80ca768bb1acf898d91ce51f7bf04
Status: Downloaded newer image for alpine:latest
Thu Jun 11 13:58:56 UTC 2071
These are the cap settings when running the container:
...
--cap-add=NET_BIND_SERVICE \
--cap-add=SYS_NICE \
--cap-drop=NET_RAW \
...
-e DNSMASQ_USER=pihole \
...
In the mean time I reverted to 2022.02.1 which still runs fine on my Pi4:
$ uname -a
Linux ******** 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux
$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
$ docker -v
Docker version 20.10.14, build a224086
TIA, Matteo
Yes, Buster is the problem. Either upgrade to Bullseye or try the user supplied link in the comments above.
Sorry, which supplied link?
On Sun, 3 Apr 2022 at 21:21, Dan Schaper @.***> wrote:
Yes, Buster is the problem. Either upgrade to Bullseye or try the user supplied link in the comments above.
— Reply to this email directly, view it on GitHub https://github.com/pi-hole/docker-pi-hole/issues/1043#issuecomment-1086931809, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANT673NOETSMDC2ZCS4QDLVDHVSDANCNFSM5SK2NPTA . You are receiving this because you were mentioned.Message ID: @.***>
Hi @dschaper and @Mellbourn,
or try the user supplied link in the comments above.
Do you mean https://github.com/pi-hole/docker-pi-hole/issues/1042#issuecomment-1086728157 i.e. https://docs.linuxserver.io/faq option 2 ?
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 04EE7237B7D453EC 648ACFD622F3D138
echo "deb http://deb.debian.org/debian buster-backports main" | sudo tee -a /etc/apt/sources.list.d/buster-backports.list
sudo apt update
sudo apt install -t buster-backports libseccomp2
Checking the results:
$ sudo apt list libseccomp2 -a
Listing... Done
libseccomp2/buster-backports,now 2.5.1-1~bpo10+1 armhf [installed]
libseccomp2/oldstable 2.3.3-4 armhf
And thanks to @julhei I'm now an happy user of 2022.04.1 🕺 .
My +1 to https://github.com/pi-hole/docker-pi-hole/issues/1042#issuecomment-1086816311.
HTH; Matteo
Yes.
This is the workaround found to work with buster host and bullseye based images.
We still suggesting to upgrade your system to bullseye as the safest path.
If you want to use buster based images, you can still use 2022.02.1
Note:
2022.02.1 (and older) are based on buster
2022.04 (and newer) are based on bullseye