Using chroot and qemu-user-static, I compiled the deps and binary on my Intel 64bit workstation (amd64 as Debian calls it) in Bookworm. Whole build takes about 20 min IIRC.
Getting everything to happen consistently and reproducibly took a few tries, but got that bashed into submission.
Upgrading at first felt messy... but I changed my build process to include a version number and build-time-stamp on the binary's filename (pihole-FTL-v5.25.2-2341-g91ea8d49-2024-12-15-163830). So, I keep of copy of the v5.25.2 binary in /usr/bin also, and just use a symlink ln -s target-name name
to point to it. That way if I accidently run pihole -up, recovery is easy.
Also made sure to do a pihole checkout
for the development branch of core, web and ftl. When ftl development checkout was done, I just went in and created the symlink to point to my newly-compiled armel binary and all was good after a pihole restartdns
. (I'm thinking that it also complained about setupVars.conf, which I copied from migration_backup_v6/ ... )
Afterthought: If upgrading to V6, don't forget to disable lighttpd...otherwise pihole might try serving http on :8080 ... I'm thinking that this may have happened to me once, and I had to fiddle with pihole-FTL --config [key]
to nudge it back to :80.
Note that this is on a non-OXNAS pogoplug. In any case, this gives me some hope for ARMv5TE/armel boxes for at least through the end of support for Debian 13/Trixie. We may hit EOL at some point after that.