2022.04.1 (Using image 334d46d0f4bd) not working on Raspbian Buster #1043
Comments
|
Same behavior as before. Log ends with |
|
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: |
|
currently working 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-stoppedThe 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 |
|
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. |
|
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 |
|
I moved the tag back, and did a |
❯ 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 |
|
|
I don't know if it's relevant, but there was an issue with the arm64 / aarch64 architectures a while back |
|
As a last ditch workaround, can you add A couple of other questions that come to mind:
|
Possibly not - we have since switched to using buildx for the multiarch images rather than our homebrew method |
|
Dug out a Pi3 from the back of a drawer. Going to try 64bit bullseye... |
|
Adding 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. |
Seems to work fine with the same compose file outlined above. I had to jump through some hoops and use compose v2 as installing 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: And on my 32 bit Pi4: What is the output of AFAIK - 64 bit Raspbian is still in beta (at least, it definitely was when it was based on 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... |
PromoFaux
added
externalbug
never-stale
PromoFaux
changed the title
PromoFaux
changed the title
FYI you can use this to get the digest corresponding to dockerhub: docker image inspect image:tag --format '{{json .RepoDigests}}' |
|
|
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 |
|
|
|
still getting |
|
I'm not sure how we can proceed on that, we don't call |
|
It is happening when accessing the web interface |
|
It looks like your system isn't allowing Since this is an issue that is unrelated to this thread, please open a new issue. |
|
2022.04.2beta did not work, it still threw |
|
2022.04.2beta did not work for me either: |
|
Ok. We need to investigate. |
|
If I remove this from my Then I get another error in the log: That error message is repeated very quickly, with some variations: |
|
FYI: |
|
What is the system time? |
|
Can you run something simple like |
|
This looks correct: |
|
Just to clarify, is that the system date or the date reported in the alpine docker container? |
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:
|
|
|
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. |
|
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 |
|
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 #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). |
Tryed, didn't fix..currently on Buster armv7. |
|
Hi, 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 2071These are the cap settings when running the container: In the mean time I reverted to $ 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 a224086TIA, |
|
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
<#1043 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AANT673NOETSMDC2ZCS4QDLVDHVSDANCNFSM5SK2NPTA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
Hi @dschaper and @Mellbourn,
Do you mean #1042 (comment) i.e. https://docs.linuxserver.io/faq option 2 ? Checking the results: And thanks to @julhei I'm now an happy user of My +1 to #1042 (comment). HTH; |
|
Yes. This is the workaround found to work with We still suggesting to upgrade your system to bullseye as the safest path. If you want to use Note: |
PromoFaux
changed the title
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:
Originally posted by @Mellbourn in #1035 (comment)
The text was updated successfully, but these errors were encountered: