Hi, I'm just posting this as an observation. Both my pi2 and zero2w get detected as Armv6 when running the 32bit Raspberry Pi OS, even though they support ArmV7. I'm not sure what happens on a pi3/4/5.
It seems like ArmV7 never gets detected. I don't know if that matters? It might save you building/maintaining the V7 binary.
This is the Pi-hole forum.
I am not sure how your issue would relate to Pi-hole.
Your output is for /usr/bin/sh:
RPi Foundation provides 32bit images targeting all Pi models, and thus have to use binaries that would be able to run on all their CPUs.
If you really like to address that your RPi OS is using v6 binaries, you should file a request with Raspberry Pi OS maintainers (or switch at least your Zero 2 W to a 64-bit image).
Hi, apologies if my post isn't clear. I'm not really flagging it as PiHole bug, just raising it as an FYI.
I believe the v6 install script detects the architecture on 32bit builds by running readelf -A /usr/bin/sh
That's why I posted the output.
Although there's a check in the script for detecting Armv7m it seems like currently that won't get triggered - at least on Raspberry Pi OS.
Some thoughts:
I could be wrong (maybe different on Debian?).
It might not matter.
You could change the detection method.
The script could be left as is - in case the foundation start to supply/target Armv7 builds.
You could stop building/maintaining the Armv7 binary if not needed.
Apologies again if this comes across as entitled or argumentative - it's not meant that way at all. It was just something I noticed while poking around. There's no real issue here just an observation.
Paul.
Sorry for the delayed reply.
Are you saying that you actually observe Pi-hole's v6 installation scripts to pull pihole-FTL binaries for ARMv6 on systems with ARMv7/8 CPUs?
Could you share readelf output for your pihole-FTL?
Thanks for replying, no worries about the delay. Yes, that's what's I'm getting at, but specifically on Raspberry Pi OS 32 bit. Sorry, that was very poorly communicated.
Is this what you need?
Kind regards,
Paul.
GitHub does offer download anonymized download counts per binary and we do see armv7 downloads so it is definitely used on some systems.
The current method is not detecting the processor itself but indeed checking other binaries on the system (sh to be precise) and downloading an FTL flavor compiled for the same target architecture your local sh binary has been compiled for. So the reason for armv6 being picked for all Raspbian images is their "laziness" to provide only a single "one-fits-all" image for all 32bit SBCs.
The reason is noted in the source code itself:
This change has been added about one year ago.
I'm kind of hesitant to change this for the exact same reasons. Even if we detect v7 using lscpu or other means, their output may be wrong in virtualized environments. On the other hand, the strategy "simply pick what we find as working elsewhere the OS" seems pretty robust.
We're always open for new input and I'd be more than happy to start a discussion about potential optimizations. At the same time I want to mention that it'd be tough to anticipate the likeliness of a failure of a new detection scheme given the multitude of virtualization providers out there. We already know it's not easy.
