I did do a quick search and also noticed below from that link I posted before:
ARM prebuilt toolchains for multiple host platforms
ARM provides it's own prebuilt toolchain based upon GNU utilities for development targeting ARM systems.
Arm GNU Toolchain
But couldnt find any armv5/armel target reference.
@bluzfanmr1 my pihole is also running a cloudflare tunnel to facilitate dns-over-https. This lead to swapping out "parts" from pihole causing the system to become very slow. Deactivating swap solved this, but then my system ran out of memory every now and then causing it to crash. So as already mentioned, I played around with swappiness, and setting it at 8 seems to solve the "slow system".
In /etc/sysctl.conf add:
vm.swappiness=8
Also added this:
vm.panic_on_oom=1
kernel.panic=10
Because last night I could not ping the device anymore after running fine for a week or so 
Anyway, what kernel are you running on the device?
Mine is running Linux pogo01 5.15.158-oxnas-tld-2 #2 SMP PREEMPT Sun May 12 18:45:05 PDT 2024 armv6l GNU/Linux
Thanks for the tips, I will check them out! I have swappiness set to 60 on the recommendation over at the Doozan forums:
# increase the free page caches for VM
vm.min_free_kbytes = 16384
vm.swappiness = 60
I'll play around a bit and look for improvement.
As far as kernel, I'm still on an older kernel:
Linux PogoplugPro2 4.14.198-oxnas-tld-1 #1 SMP PREEMPT Sun Sep 20 22:15:05 PDT 2020 armv6l GNU/Linux
I have never been able to get to the 5.xx.xx kernel version with my Pro. I have tried and tried but there is something weird that keeps it from working. Even totally from scratch.
My other pogoplug with pihole v5 is also running that kernel and I have never seen it crash. Gonna switch to that one again during the weekend.
Thanks for the update.
In regards to my issues with pihole v5, I found the problem, it seems.
There was a problem with user "www-data". This user had an entry in /etc/passwd, but did not have an entry in /etc/shadow.
Once I fixed that, the webif is working normally.
The bigger question is why this is not working out-of-the-box. I'm not sure when Debian creates the www-data user, and why there was no entry in /etc/shadow for said user. I don't know if it is a script/function in apt/dpkg in Debian, in the install of lighttpd, that creates the www-data user and sets up both /etc/passwd and /etc/shadow - I'm doubting that www-data should be a default user and group in a minimal rootfs... seems like it would only be added in for software packages that require it.
I may try to create a fresh rootfs from debootstrap and see what exactly is going on that caused this problem.
==========
Also, I successfully compiled v6 (v5.25.2-2341-g91ea8d49) both natively on the pogoplug V2, as well as in a chroot (with qemu) environment on my intel 64 bit workstation. Native compilation (the dependencies and pihole-FTL) took about 2+ hrs, and on the workstation, much less.
Still need to get some problems worked out for the v6 ... they may be caused by permissions/user issues also.
I'm not sure... did you try to install Apache or a different web server any time before installing Pi-hole? I think this user is created when you install a web server.
It was a pristine/fresh rootfs that I used. No web server installed before running the standard install script for Pihole (which did, of course, install lighttpd).
I'm wondering if there is something in the ordering of the installations that could be the issue. Or if something like the "locales" package (or the lack of its preconfiguration) that could trigger a problem in the install.
In the rootfs that "we" < meaning the community of Debian Kirkwood users at Doozan Forums > use, the "locale" and "language" is not set... that may be upsetting to libpcre (which is a dependency which is a dependency for lighttpd, IIRC).
Your post jogged my memory about this issue, and the fix. See here:
/etc/passwd issue fix for Pogoplug
I'm not smart enough to figure out the why.
I'm not sure if Bodhi's rootfs have the base-passwd package installed. It is counterintuitive, but docs say that the webserver packages in Debian **do not ** add in the www-data user and group.
That, per docs, is done by base-passwd ... Debian -- Details of package base-passwd in bookworm
I believe the www-data user comes default OOTB with a basic Debian install.
Below is also from a (minbase) debootstrapped Debian with no web daemon installed:
$ hostnamectl
Static hostname: gam02
Icon name: computer-vm
Chassis: vm
Virtualization: xen
Operating System: Debian GNU/Linux 12 (bookworm)
Kernel: Linux 6.1.0-13-amd64
Architecture: x86-64
$ apt policy lighttpd apache2
lighttpd:
Installed: (none)
Candidate: 1.4.69-1
Version table:
1.4.69-1 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
apache2:
Installed: (none)
Candidate: 2.4.57-2
Version table:
2.4.57-2 500
500 http://deb.debian.org/debian bookworm/main amd64 Packages
$ grep www-data /etc/passwd
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
$ sudo grep www-data /etc/shadow
www-data:*:19642:0:99999:7:::
Looks like the base-passwd package is responsible for that:
$ apt show base-passwd
[..]
Description: Debian base system master password and group files
These are the canonical master copies of the user database files
(/etc/passwd and /etc/group), containing the Debian-allocated user and
group IDs. The update-passwd tool is provided to keep the system databases
synchronized with these master files.
$ apt policy base-passwd
base-passwd:
Installed: 3.6.1
$ less /usr/share/doc/base-passwd/README
base-passwd for Debian
----------------------
This package supplies the "master" copies of /etc/passwd and /etc/group,
in /usr/share/base-passwd.
[..]
* the home directory for the www-data user is preserved
$ dpkg -L base-passwd
[..]
/usr/share/base-passwd
/usr/share/base-passwd/group.master
/usr/share/base-passwd/passwd.master
$ cat /usr/share/base-passwd/passwd.master
[..]
proxy:*:13:13:proxy:/bin:/usr/sbin/nologin
www-data:*:33:33:www-data:/var/www:/usr/sbin/nologin
backup:*:34:34:backup:/var/backups:/usr/sbin/nologin
Not sure though how the shadow file is populated.
Thanks @deHakkelaar for that confirmation...that is my understanding also. OOTB in this case means (to me) "with update-passwd installed and working correctly".
I will try to test this by creating a rootfs from scratch.
Its part of the minbase:
$ sudo debootstrap --variant=minbase --print-debs bookworm dummy_folder
[..]
adduser
apt
base-files
base-passwd
bash
bsdutils
coreutils
dash
debconf
debian-archive-keyring
debianutils
diffutils
dpkg
e2fsprogs
findutils
gcc-12-base
gpgv
grep
gzip
hostname
init-system-helpers
libacl1
libapt-pkg6.0
libattr1
libaudit-common
libaudit1
libblkid1
libbz2-1.0
libc-bin
libc6
libcap-ng0
libcap2
libcom-err2
libcrypt1
libdb5.3
libdebconfclient0
libext2fs2
libffi8
libgcc-s1
libgcrypt20
libgmp10
libgnutls30
libgpg-error0
libhogweed6
libidn2-0
liblz4-1
liblzma5
libmd0
libmount1
libnettle8
libp11-kit0
libpam-modules
libpam-modules-bin
libpam-runtime
libpam0g
libpcre2-8-0
libseccomp2
libselinux1
libsemanage-common
libsemanage2
libsepol2
libsmartcols1
libss2
libstdc++6
libsystemd0
libtasn1-6
libtinfo6
libudev1
libunistring2
libuuid1
libxxhash0
libzstd1
login
logsave
mawk
mount
ncurses-base
ncurses-bin
passwd
perl-base
sed
sysvinit-utils
tar
tzdata
usr-is-merged
util-linux
util-linux-extra
zlib1g
$ man debootstrap
[..]
--variant=minbase|buildd|fakechroot
Name of the bootstrap script variant to use. Cur‐
rently, the variants supported are minbase, which only
includes required packages and apt; buildd, which in‐
stalls the build-essential packages and fakechroot,
which installs the packages without root privileges.
The default, with no --variant=X argument, is to cre‐
ate a base Debian installation with all packages of
priority required and important, including apt.