pihole exited with code 132 on "Raspberry Pi Model B Rev 2" from versions > than 2022.07.1

[imay-dil]

This is a: Run Issue

Details

Went to upgrade today, and noted anything after pihole/pihole:massive-refactor seems to cause my pihole container to exit with "pihole exited with code 132". Dont get anything in the docker logs. I'm running an older version of the rasberry pi (which is running docker).

heres the output of cpuinfo in case it helps

processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2835
Revision        : 000e
Serial          : 00000000014ae371
Model           : Raspberry Pi Model B Rev 2

~ $ docker --version
Docker version 20.10.5+dfsg1, build 55c4c88

~ $ uname -r
5.15.61+

~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
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"

Any version I try prior to this one works fine. for example pihole/pihole:2022.07.1 works great.

Related Issues

• [ ] I have searched this repository/Pi-hole forums for existing issues and pull requests that look similar

How to reproduce the issue

1. Environment data

• Operating System: Raspbian bullseye (11)
• Hardware: Raspberry Pi Model B Rev 2
• Kernel Architecture: ARMv6
• Docker Install Info and version:
  • Software source: official docker-ce
  • Supplimentary Software: portainer (but have tryed it without just in docker compose)
  • Hardware architecture: ARMv6

2. docker-compose.yml contents, and docker run shell command

 ~ $ cat docker-compose.yml
version: "3"
services:
  pihole:
    container_name: pihole
    image: pihole/pihole:massive-refactor
    dns:
      - 127.0.0.1
      - 8.8.8.8
    environment:
      TZ: "Pacific/Auckland"
      WEBPASSWORD: "this_is_not_a_real_password"
      DHCP_ACTIVE: "true"
      DHCP_START: "10.22.60.80"
      DHCP_END: "10.22.60.254"
      DHCP_ROUTER: "10.22.60.66"
      PIHOLE_DOMAIN: "keylimepie"
      WEBTHEME: "default-darker"
    volumes:
      - './pihole/etc/:/etc/pihole/'
      - './pihole/dnsmasq.d/:/etc/dnsmasq.d/'
    cap_add:
      - NET_ADMIN # DHCP needs NET_ADMIN
    restart: unless-stopped
    network_mode: "host"
    logging:
      driver: "json-file"
      options:
        max-file: "10"
        max-size: 10m

then when running

 ~ $ docker-compose up
pihole exited with code 132
pihole exited with code 132
pihole exited with code 132

These common fixes didn't work for my issue

• [x] I have tried removing/destroying my container, and re-creating a new container
• [x] I have tried fresh volume data by backing up and moving/removing the old volume data
• [x] I have tried running the stock docker run example(s) in the readme (removing any customizations I added)
• [x] I have tried a newer or older version of Docker Pi-hole (depending what version the issue started in for me)
• [x] I have tried running without my volume data mounts to eliminate volumes as the cause

only applies to versions >= docker pull pihole/pihole:massive-refactor

[imay-dil]

just want to say - happy with the 2022.07.1 so i'm not loosing sleep over this just thought i'd point it out in case any one bumps in to the same issue. Also wanted to say great work - much love

❤️

[PromoFaux]

Whoops, I forgot to delete the massive-refactor tag, that was only up for testing :)

Do you see exactly the same with latest? Can you also try with PH_VERBOSE set to 1, which will hopefully give us a bit more detail in the output

[imay-dil]

sure can - its in latest. I think i tryed everything from latest back down and the refactor one was where it started happening.

PH_VERBOSE is an environment variable for the container I assume ?

[PromoFaux]

Sorry I probably should have been more verbose with my request... :)

Yes please, set that as an environment variable

[imay-dil]

lol - all good. used upper case, nothing to write home about. I think it just doesnt like my architecture (ARMv6). It is a very old pi to be fair. output below, not that its much more help.

  pihole:
    container_name: pihole
    image: pihole/pihole:latest
      #    image: pihole/pihole:2022.07.1
    dns:
      - 127.0.0.1
      - 8.8.8.8
    environment:
      PH_VERBOSE: 1
... <snip> ...

~ $ docker-compose up
pihole exited with code 132
pihole exited with code 132
pihole exited with code 132
pihole exited with code 132
pihole exited with code 132
pihole exited with code 132

in another window ....

~ $ docker logs pihole

:tumbleweed:

[imay-dil]

also tried

~$ sudo journalctl -fu docker.service
~$ sudo tail /var/log/daemon.log  -f

but I didn't see anything interesting.

Also switched back to 2022.07.1 and the logs where very chatty, so i assume the environment variable worked. I just dont think docker is getting as far as handing off fully to the container when I use the newer ones.

Looked at the diff between the tags and noted detect_arch() in src/scripts/install.sh in github. Please dont confused this for me knowing what I'm doing, lol. Saw there was a case statement for arch so in case it helps, I ran the dpkg command

~ $ dpkg --print-architecture
armhf

tbh I'm not sure what armhf is - maybe time for some googling as initial search just confused me more. On Debian based systems it seems to be synonymous with armv7. Did stumble across this:

• https://raspberrypi.stackexchange.com/questions/87392/pi1-armv6-how-to-disable-armhf-packages/87403#87403

if I run trusty uname -a it seems to imply armv6 rather than 7 Linux keylimepie 5.15.61+ #1579 Fri Aug 26 11:08:59 BST 2022 armv6l GNU/Linux

[imay-dil]

i was able to pull an image of latest, rename it and then open it up for a play.

~$ docker commit 7236acf3c247 debug/pihole
~$ docker run -it  --entrypoint sh debug/pihole

starting /s6-init directly in the container results in "core dumped"

ran dpkg --print-architecture from inside the container I was surprised to see it returned armel rather than armhf like the host. It was my intention to try and swap out s6-init from the hf version to the arm version.

After a bit of messing around, I replaced the /s6-init arm version with the armhl version instead.

(note I'm assuming it was the arm version originally based of the case statement in /usr/local/bin/install.sh. I'm also assuming this script runs in the container but I could be way off).

Anyhoo ~ after all this starting /s6-init directly in the container it it looked like it got a little further with s6-overlay-suexec: fatal: can only run as pid 1

so I took another commit of the container this time as debug/pihole2 and after exiting it and re-starting it with an entry point of /s6-init, the container stays open and logs normally. ~~I couldn't log into the web interface , but thats ok as i messed about a fair bit in the image and I normally run it under the host network but not for this check, so thats likely on me.~~ (update - ran it with --network host and webui loaded fine)

I'm not sure why any of this worked as I expected it to be the other way round, as in working with arm version not the armhf version !

I really dont know enough to know if this info is helpful.

Is it expected that the architectures on the host and in the container match? If so I guess its something to do with my pi set up and you should feel free to close this issue.

[danitorregrosa]

Hi:

I am also affected by this issue (same raspberry model).

The error comes from included s6-overlay binaries, that are compiled for ARMv7. Executing any ot them in raspberry pi 1 cpu (ARMv6) ends with a ilegal instruction:

# md5sum /command/s6-overlay-suexec
5f4e1ce7bc14fb39d47066d138454167  /command/s6-overlay-suexec
# /command/s6-overlay-suexec
Illegal instruction (core dumped)

Their new toolchain definition (https://github.com/just-containers/s6-overlay/blob/master/conf/toolchains) defines raspberry pi 1 as armhf architecture. And their arm definition is now an ARMv7 (genericv7a) compilation, so no compatible with rpi1 cpu.

Debian included in docker image outputs armel as architecture in rpi1, so modifying install.sh (https://github.com/pi-hole/docker-pi-hole/blob/master/src/s6/debian-root/usr/local/bin/install.sh) so that armel generates S6_ARCH="armhf";; (instead of arm) builds a rpi1 compatible image. I have build a successful local image with this change.

Note: It appears that older s6-overlay binaries in their arm architecture were ARMv5 binaries, so apparently they have moved (on purpose or by mistake) to ARMv7 during their v3 move.

e.g., version v2.2.0.3:

armhf
# readelf -A s6-overlay-armhf.v2.2.0.3/bin/s6-echo
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_ABI_optimization_goals: Aggressive Size

arm
# readelf -A s6-overlay-arm.v2.2.0.3/bin/s6-echo
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_optimization_goals: Aggressive Size

and in v3.1.2.1:

armhf:
# readelf -A s6-overlay-armhf.v3.1.2.1/command/s6-echo
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_ABI_optimization_goals: Aggressive Size
  Tag_CPU_unaligned_access: v6

arm:
# readelf -A s6-overlay-arm.v3.1.2.1/command/s6-echo
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_optimization_goals: Aggressive Size
  Tag_CPU_unaligned_access: v6

[PromoFaux]

It's possible I got something wrong here:

https://github.com/pi-hole/docker-pi-hole/blob/988c39581e8a58f28ba39c40a474ea8f139a4686/src/s6/debian-root/usr/local/bin/install.sh#L12-L27

I had to change it a bit because they named things slightly differently between v2 and v3... will try to look in a bit more detail later on

[PromoFaux]

What is the output of dpkg --print-architecture on your machine?

[danitorregrosa]

What is the output of dpkg --print-architecture on your machine?

In host SO (raspbian), armhf:

# dpkg --print-architecture
armhf

But inside docker image (debian), armel. This is the one that install.sh uses:

# docker run --rm -ti --entrypoint="" pihole/pihole:2022.09.1 /bin/sh
# dpkg --print-architecture
armel

[PromoFaux]

Not had my morning coffee yet, yeah clearly it's the one inside docker image that we need :) doh!

So what we're saying here is that the cases need changing in install.sh - I'm away from my development PC right now, but if you are happy to PR the changes, we can try them out in dev and then tag a new one if it works

[danitorregrosa]

I'm going out right now and I will be without laptop for two weeks. I'm sorry :D I will do in two weeks if it's not done yet

[danitorregrosa]

I have run latest dev docker image in a "Raspberry Pi Model B Rev 2" and confirm that now it starts ok.

# docker run --rm pihole/pihole:dev
Unable to find image 'pihole/pihole:dev' locally
dev: Pulling from pihole/pihole
705abbab4fcb: Already exists 
ebfcef144b1d: Already exists 
4f4fb700ef54: Already exists 
d843eb105095: Pull complete 
7f5515982d9a: Pull complete 
dcec16e40167: Pull complete 
62f0978589e7: Pull complete 
Digest: sha256:57cb1c6f98c38379077224705a0478e06d51a1501a0ce1c4eaaa5d8bf36d3ac2
Status: Downloaded newer image for pihole/pihole:dev
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
...

@imay-dil could you test it in your raspberry to confirm, please? Thank you.

@PromoFaux, looking at s6_overlay's archs:

• Their toolchains are defined in https://github.com/just-containers/s6-overlay/blob/master/conf/toolchains
• And their binaries tag are generated with: https://github.com/just-containers/s6-overlay/blob/518892490f589b2770fff5b199e46c7c4d08e478/Makefile#L9 HW := $(if $(findstring arm-linux-musleabihf,$(ARCH)),armhf,$(firstword $(subst -, ,$(ARCH))))

Their arm arch is for a genericv7a cpu.

So, i addition to this issue fix, may be a good idea to also modify:

  armhf)
    S6_ARCH="armhf";;   <== modify this to "arm"  ???

I' m not sure what cpu is expected for "armhf)" here, but if it is oriented to armv7+ cpu, modify S6_ARCH to "arm" will be an optimization, right? (I don't have hardware to test it and I'm not sure about it, so I leave it on your hands, @PromoFaux. Thank you.)

[PromoFaux]

I don't have hardware to test it and I'm not sure about it,

To be completely honest, I've not much of a clue about things when it comes to the multi-arch stuff - mostly chucking stuff at the wall and seeing what sticks!

So we can either try your suggestion here, and see if anyone says it stops working - or we can leave it until someone comes along and says something is not working as they would expect with armhf (I'm unsure what hardware would be required for this?)

[RichardHyde]

The current dev image worked for me when the latest image exited with error 132 on a Raspberry Pi Zero

[notedeagle]

The same for me. Dev works :D

[imay-dil]

sorry for the belated reply. Dev works here too.

[imay-dil]

Just wanted to extend my thanks to @danitorregrosa and @PromoFaux !