Franklin Timóteo's picture

I am trying to put in the pihole in TKL. The pihole installation script seems to run normally, but stops at the Pi-hole-FTL engine restart. 

root@tkldev .../products/pihole# echo $CHROOT_ONLY

root@tkldev .../products/pihole# make
root@tkldev .../products/pihole# fab-chroot build/root.patched/


Trying manually inside root.patched:

root@tkldev /# bash /usr/local/src/Pi-hole/automated\ install/


Jeremy Davis's picture

Hi Franklin, welcome to TurnKey.

That certainly seems like a strange one!?

Unfortunately, it's not uncommon for these sort of generic install scripts to fail on TKLDev. They often don't play nice with TKLDev because they're generally developed with the intention of installation on an end user system, rather than as part of a build process. The TKLDev build environment is essentially just a chroot and doesn't provide a complete "proper" environment as a complete system would. Services in particular are often problematic.

I just had a go myself and whilst it also failed for me, my output looked very different to yours? Mine has the same output (and fails at the same place) as your manual install!? The TKLDev output you show from your automated build appears to be quite different to mine?! Did you enable some debugging setting or something? Here's mine:

  [i] Restarting services...
  [✓] Enabling pihole-FTL service to start on reboot...
  [i] Restarting pihole-FTL service...make: *** [/usr/share/fab/ build/stamps/root.patched] Error 1

Regardless, poking around it appears that the issue is that the systemctl command exits with a non-zero exit code (indicating an error) and because the build process stops on errors, it stops...

I'm not sure what other issue you might encounter, but that one can be worked around by appending ' || true' on the end of the line that calls 'systemctl restart' (so that it never returns a non-zero exit code). Here's a one liner:

sed -i '\|systemctl restart "${1}" &> /dev/null| s/$/ || true/' path/to/

(Where path/to/ is the actual path to the script).

After doing that it appears to complete successfully. I haven't tested it's usage at all though.

To get it to a point where the resulting ISO can be used though, you'll likely need to do some additional firstboot config. That will ensure that all the relevant settings are reconfigured for the new installed system.

Franklin Timóteo's picture

Thanks for replying Jeremy!

sed -i '\|systemctl restart "${1}" &> /dev/null| s/$/ || true/' path/to/

The above line did not solve it. But it gave me an idea to remove restart. It seems to have worked.




To get it to a point where the resulting ISO can be used though, you'll likely need to do some additional firstboot config. That will ensure that all the relevant settings are reconfigured for the new installed system.

I think I should add some things like:

pihole reconfigure 
pihole -a -p (pihole change password)


Jeremy Davis's picture

No worries. Sorry I'm not always as quick as I'd like.

Great work on the work around. Glad you got it working. Removing the restart altogether is a great idea.

I can't help much as I'm not at all familiar with pihole, but on face value, your suggestions seem pretty good.

I imagine that you'll also want to set a static IP too (by default a TurnKey server will get an IP via DHCP).

If you know any python, you could create interactive first boot scripts like the ones we provide for other appliances. That's a project we call Inithooks. Beyond reading, you could have a look at another appliance to get a feel for what custom pihole inithooks might look like. E.g. have a look at the overlay/usr/lib/inithooks/ directory of our Domain Controller. They usually consist of one or 2 bash scripts (in /usr/lib/inithooks/firstboott.d) that call a python script (in /usr/lib/inithooks/). If you'd rather not, that's cool, just thought I'd share.

Franklin Timóteo's picture

Hello Jeremy!

I am having some problems with the construction.
Initially it seems that localhost:3128 becomes unavailable after some build. After a few seconds/minutes it becomes available again as in the gist below.


Setting CHROOT_ONLY=no also does not generate the iso.

If you can, take a look at my repository.
Thanks for the heads up Jeremy!


Jeremy Davis's picture

In TKLDev squid is set up as a (caching) download proxy. The output you shared suggests that may have crashed. Check my guess like this

systemctl status squid

If it has crashed, perhaps the first thing to check is free space:

df -h /
Franklin Timóteo's picture

Sorry, I forgot the variable CHROOT_ONLY in bashrc.d.
Anyway if you can evaluate the code on github.




Jeremy Davis's picture

I did a test run of your code and it wasn't working for me. I had a quick look and refactored the build code. Here my changes:

As I noted on the PR, I haven't tested the ISO (obviously don't use CHROOT_ONLY if you want to build an ISO).

Franklin Timóteo's picture

Hello Jeremy!
After your pull request things worked out perfectly.
It took me a while to understand that the inithooks scripts needed to be in python.

I wonder if the code below makes sense in my tkl. I haven't finished reading my shell book yet.

. /etc/default/inithooks


Much of it I copied from the turnkey-apps scripts, the readability is very good.

I know that the code below could be done with python substitution functions, but it will take about 4-5 lines because of the opening of the file and its manipulation with the line. Using call with sed seems readable to me.


    call(['sed', '-ri', '/  "\$\{opt1a\}"  "\$\{opt1b\}" ./d', basicinstall])
    call(['pihole', 'reconfigure'])
    call(['git', 'checkout', basicinstall])

Thank you for your attention to a beginner.
Do you think it would be interesting to have Pi-hole as part of turnkey-apps?

Add new comment