Building Pi-hole v6.0 on Pogoplug V2

Thank you for your messages. The pogoplug is using a rootfs provided by the doozan community and is a pretty "standard" debian (bookworm) install AFAICS. So it is not running busybox, but a real shell:

root@debian:~#  readlink -f /bin/sh
/usr/bin/dash

It is indeed starting up via sys V init, no systemd:

root@debian:~# apt policy systemd
systemd:
  Installed: (none)
  Candidate: 252.31-1~deb12u1
  Version table:
     252.31-1~deb12u1 500
        500 http://ftp.us.debian.org/debian bookworm/main armel Packages
     232-25 -1
        100 /var/lib/dpkg/status

No idead if these boxes are able to start via systemd or not ... appart from faster boot times, is there any benefit running systemd instead of good old sys V init?

The haveged is needed for something I tried to describe here: Adding a SATA SSD to a PogoPlug Pro

Once you start adding services (like sshd, pihole-FTL) these suffer from entropy starvation, causing the system to start very slowly and some services (like pihole-FTL) even fail start. I found somewhere on the Internet that installing haveged fixes this and in my case, indeed it did.

In the same blogpost you can read I added an SSD ... so no SD-cards here, but "real" disks :wink: so running smartd makes sense here.

About the whole syslogd / klogd thing ... very unsure here. I thought klogd was feeding syslogd, could be wrong. Either way, this is a standard rootfs without any modifications made ... so no idea if I need both klogd and syslogd

2 Likes

Hi @kennywest

I also use bodhi’s rootfs from the Doozan site.

Ive tried systemd years back but it was slower and if I remember correctly it also used a bit more memory.

I remember there was a choice between rng and havegd … also went with havegd, and I think part of the problem may have been that SSL or something cryptological needed that entropy. It may have been lagging when it was generating keys.

I currently have avahi, monit and smartd running on my 128MB Pogo V4 Pihole (V5) but will take those off if and when I upgrade it to V6.

Thanks for leading the way!

2 Likes

It doesnt have to be the shell thats symlinked to busybox.
I found another distro I have here that applies busybox (XBian on a Pi):

$ printenv SHELL
/bin/bash
$ readlink -f /bin/bash
/usr/bin/bash
$ readlink -f /usr/sbin/udhcpc
/usr/local/bin/busybox.armhf

Like the busybox help explained, its possible to symlink any executable to busybox.

Am not sure why they apply busybox-syslogd.
Maybe because of speed/memory/load considerations.
My mistake at first was that I believed it to be the other:

$ apt-file search bin/syslogd
busybox-syslogd: /sbin/syslogd
inetutils-syslogd: /usr/sbin/syslogd
$ apt show inetutils-syslogd
[..]
Description: system logging daemon
 The syslog daemon is responsible for providing logging of messages
 received from programs and facilities on the local host as well as
 from remote hosts.

Maybe the man pages (if installed) explain how the two relate?

$ apt-file list busybox-syslogd
[..]
busybox-syslogd: /usr/share/man/man8/klogd.8.gz
busybox-syslogd: /usr/share/man/man8/syslogd.8.gz

They could if you install systemd and remove the currently installed init:

$ dpkg -S /sbin/init
sysvinit: /sbin/init

As noted before:

Most of the packages can be started with old school sysV init.d scripts or as a service for systemd.
And systemd can cope with init.d scripts too with something thats called systemd-sysv-generator.

But my guess is that this "doozoan community" chose sysv over systemd for speed/memory/load considerations.
Just guessing ... not sure though!

EDIT: Oh is it sysv?
Bc there are others like runit or maybe even upstart that are sometimes used.

$ apt show runit-init
[..]
Description: system-wide service supervision (as init system)
 runit is a collection of tools to provide system-wide service supervision
 and to manage services.  Contrary to sysv init, it not only cares about
 starting and stopping services, but also supervises the service daemons
 while they are running.  Amongst other things, it provides a reliable
 interface to send signals to service daemons without the need for pid-files,
 and a log facility with automatic log file rotation and disk space limits.
 .
 This package provides /sbin/init as a symlink to runit-init so that the system
 will automatically boot with runit; it also provides compatibility symlinks
 (shutdown, halt, reboot, poweroff) that are expected by desktop environments
 and other system tools.
 To install this package the user need to first remove the `init' metapackage,
 for more details see #1005881 or visit
 https://salsa.debian.org/runit-team/runit-wiki/-/wikis/home

EDIT2: Oh I noticed below:

$ apt depends busybox-syslogd
busybox-syslogd
  PreDepends: init-system-helpers (>= 1.54~)
 |Depends: busybox (>> 1:1.35.0)
[..]

Yeah I shoot that one down on any of my servers with below:

sudo systemctl disable --now avahi-daemon.service

EDIT: Oh for sysv, that would be below :wink:

sudo update-rc.d avahi-daemon disable

1 Like
klogd
    klogd [-c N] [-n]

    Log kernel messages to syslog

I don't think that monit has ever restarted anything except sshd... and that is after the rsync run of the databases.

Probably not essential, but not nice to be unable to log in if sshd does crap out.

1 Like

I'm also needing to build V6 pi-hole on my Pogoplug V4. This references https://github.com/pi-hole/docs/blob/release/v6.0/docs/ftldns/compile.md as a starting point, but I get 404 page not found when I click it. Is it somewhere else now?

rsantag, this is all that I can find right now... I'm not sure about version numbers, etc...

https://github.com/pi-hole/docs/blob/ad10ab7b84689cc5ab1dcbe68bf79fff98e4c04a/docs/ftldns/compile.md

Depending on schedule this next week, I may post something in terms of building native, building w/ qemu & chroot, and running this on a minimal (128MB RAM) Pogoplug. I have a minimal Debian Trixie (next release due up) tarball that runs nicely.

I have it running on both a V2 and a V4 Pogoplug. The V4 setup requires a paring back of other services so that memory isn't an issue. Uptime 2 weeks with no hiccups.

OK, thank you. It's building now.

So one more question, and I hope this isn't a dumb question: "pihole -up" fails because my CPU architecture isn't supported, and using curl to do a fresh install also fails for the same reason, so how do I install/update the other two components - pi-hole core and the web interface? If I update the FTL binary on an existing 5.18.4 install, will "pihole -up" see that FTL is up-to-date and only update web and core?

My installs so far have been upgrade-installs from a previous v5. (I have never done a bare-metal install of V6 on the armel devices.

I know there is an env flag that you can use to suppress checking for OS... not sure how that works ...

OK, this thread gives some details but is rather old…

Maybe:


PIHOLE_SKIP_OS_CHECK=true pihole -up

IIRC, it may indeed install the web and core-scripts correctly and simply fail on the pihole-FTL binary.

OK, got pihole-FTL compiled, but doing pihole -up with "PIHOLE_SKIP_OS_CHECK=true" didn't work.

 [i] SELinux not detected
  [✓] Update local cache of available packages

  [✓] Checking apt-get for upgraded packages... 59 updates available
  [i] It is recommended to update your OS after installing the Pi-hole!

  [✓] Building dependency package pihole-meta.deb
  [✓] Installing Pi-hole dependency package

  [i] PIHOLE_SKIP_OS_CHECK env variable set to true - installer will continue
  [i] Performing unattended setup, no dialogs will be displayed
  [i] Performing reconfiguration, skipping download of local repos
  [✓] Resetting repository within /etc/.pihole...
  [✓] Resetting repository within /var/www/html/admin...
  [✓] Checking for user 'pihole'

  [i] FTL Checks...

  [✗] This processor architecture is not supported by Pi-hole (v5TE)  [i] Downloading and Installing FTL...curl: (3) bad range in URL position 70:
https://github.com/pi-hole/ftl/releases/latest/download/pihole-FTL  [i] Detectin  [✗] This processor architecture is not supported by Pi-hole (v5TE)
                                                                     ^
  [✗] Downloading and Installing FTL
   Error: URL https://github.com/pi-hole/ftl/releases/latest/download/pihole-FTL  [✗] This processor architecture is not supported by Pi-hole (v5TE) not found
  [✗] FTL Engine not installed

  Unable to complete update, please contact Pi-hole Support

Other ideas? How have you been able to update armel devices to V6?

I'm going to try an install to a fresh rootfs tomorrow (on a USB-SATA drive) and see how to come up with a solution...

I know that the command pihole checkout web master for instance downloads the components needed for the web root, and pihole checkout core master does so for the scripts... I don't think that it installs them in the correct places nor does it set permission, IIRC... but at some point I cobbled together a what-if-there-is-no-working-installer-for-my-arch list of things to do...

I somehow managed to get Core and Web interface updated to V6 (using pihole -up). Initially the dashboard showed they were still on V5, but today it is showing everything is on V6. I need to see if I can come up with a update process that's reproducible.

OK, it seems like a reboot is all that was needed for the dashboard to show that everything is now V6.

These were my steps, if it's any help for anyone else.

  1. Updated Debian to v12.9 with apt-get update and apt-get upgrade
  2. Stop pihole-FTL and copy in the new one I compiled following the info at https://github.com/pi-hole/docs/blob/f47ded3c01cd4a6f834c6455a2677530c089ac2a/docs/ftldns/compile.mdMake sure owner:group is root:root and permissions are 755
  3. Stop lighttpd and uninstall it
  4. Enabled a 256MB swap file and set /etc/fstab to enable it on a reboot.
  5. Created /etc/sysctl.d/local.conf and added "vm.swappiness=20" to it.
  6. Run "pihole -up". You'll get the "processor architecture is not supported" error in the FTL checks.
  7. Start pihole-FTL (/etc/init.d/pihole-FTL start)
  8. Bring up the web GUI and set the upstream server in Settings/DNS, as it didn't seem to carry over from the V5 settings.
  9. At this point the Dashboard still shows that Core and Web interface are on V5, but after a reboot they showed the correct V6 versions.

Glad that worked out.
I have disconnected my plug for now, since it seems to drop network connections every now and then. The device becomes unreachable via the network (no ping, no ssh, nothin). So I need to attach a serial console, let it run for some time, and should it become unresponsive again, check the console.
So for now, I switched to a VM on my proxmox server to run pi-hole.

OK, I'm seeing some issues - some things still seem to be V5, so I think pihole -up failed to update more than just FTL. I'll continue researching...

So, everything in /opt/pihole seems to be V5, /usr/local/bin/pihole is V5. When I try to update Gravity from the web interface I get a "sudo: a password is required" error. I'm sure there's other stuff too.

I'm not sure trying to knock out the issues one at a time is going to be the way to go because large chunks of code are obviously out of sync. If anybody has successfully migrated from V5 to V6 on the Pogoplug, I would sure like some hints on how you were able to do it.

To start, try these commands and post back:

uname -a
cat /etc/issue
cd /opt/pihole
./updatecheck.sh      
./version.sh      # N.B. : same as 'pihole -v'

For comparison, I got:

Linux trixie-debian-armel 6.12.6-kirkwood-tld-1 #1 PREEMPT Thu Dec 19 14:57:30 PST 2024 armv5tel GNU/Linux
Debian GNU/Linux trixie/sid \n \l
Core version is v6.0.4 (Latest: v6.0.4)
Web version is v6.0.1 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)
root@pihole:~# myinfo
pihole
192.168.1.157
Pogoplug v4
Linux version 6.6.3-kirkwood-tld-1 (root@tldDebian) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 PREEMPT Tue Nov 28 23:25:58 PST 2023
Debian 12.7
Tue Feb 25 09:24:33 CST 2025 up 14 hours, 25 minutes
root@pihole:~# cd /opt/pihole
root@pihole:/opt/pihole# ./updatecheck.sh
root@pihole:/opt/pihole# ./version.sh
Core version is v6.0.4 (Latest: v6.0.4)
Web version is v6.0.1 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)
root@pihole:/opt/pihole#

Looking at what you posted, you seem to be running V6. (the bottom of the main web dashboard page should show something like Core v6.0.4 FTL v6.0.2 Web interface v6.0.1). Please check that also for sanity/agreement.

You are correct: knock out/fix/address one problem at a time...

How is your memory usage profile looking?

free -h ;  ls -lsh /dev/shm

for comparison, I get

root@trixie-debian-armel:/opt/pihole# free -h; ls -lsh /dev/shm
               total        used        free      shared  buff/cache   available
Mem:           107Mi        40Mi       9.8Mi       3.7Mi        66Mi        66Mi
Swap:          1.0Gi        13Mi       1.0Gi
total 5.2M
   0 drwxrwxrwt  2 root   root    380 Feb 21 21:51 .
   0 drwxr-xr-x 13 root   root   2.8K Feb 18 10:17 ..
   0 -rw-r--r--  1 root   root      0 Feb 18 10:17 .tmpfs
332K -rw-------  1 pihole pihole 332K Feb 21 21:51 FTL-26209-clients
4.0K -rw-------  1 pihole pihole 4.0K Feb 21 21:51 FTL-26209-clients-lookup
4.0K -rw-------  1 pihole pihole  328 Feb 21 21:51 FTL-26209-counters
316K -rw-------  1 pihole pihole 316K Feb 25 10:51 FTL-26209-dns-cache
 36K -rw-------  1 pihole pihole  36K Feb 25 09:14 FTL-26209-dns-cache-lookup
156K -rw-------  1 pihole pihole 156K Feb 25 09:14 FTL-26209-domains
 16K -rw-------  1 pihole pihole  16K Feb 22 02:49 FTL-26209-domains-lookup
548K -rw-------  1 pihole pihole 548K Feb 25 02:47 FTL-26209-fifo-log
4.0K -rw-------  1 pihole pihole   56 Feb 21 21:51 FTL-26209-lock
 12K -rw-------  1 pihole pihole  12K Feb 21 21:51 FTL-26209-overTime
4.0K -rw-------  1 pihole pihole 4.0K Feb 21 21:51 FTL-26209-per-client-regex
2.9M -rw-------  1 pihole pihole 2.9M Feb 25 07:55 FTL-26209-queries           ###<<<<<< This can grow quite a bit and force the system to start using swap... which can be a big problem
768K -rw-------  1 pihole pihole 768K Feb 25 00:49 FTL-26209-recycler
4.0K -rw-------  1 pihole pihole  136 Feb 21 21:51 FTL-26209-settings
160K -rw-------  1 pihole pihole 160K Feb 25 09:39 FTL-26209-strings
 12K -rw-------  1 pihole pihole  12K Feb 21 21:51 FTL-26209-upstreams

I'll be interested in seeing what your FTL-queries shared memory usage looks like. That is the part that can grow quite a bit and cause the system into sustained swap usage, which causes a slowdown, and then unresponsiveness and sometimes/eventually a crash.

There are some easy ways to mitigate that... but lets see the full picture before jumping to fixes/adjustments.