Pi-hole on Debian Bullseye

Help Community Help
#1

Hello,
since Bullseye release is near and actual pre release is running fine already, I decided to test Pi-hole on it.
Except the webinterface everything is working.
It seems that the lighttpd config is not compatible because after Pi-hole installation lighthttpd does not start any longer. I restored default config and lighttpd starts again. I will use Pi-hole without webinterface and maybe I will try to figure out what causes lighttpd to crash with Pi-hole config file.
If someone already has a solution please reply to this post.

greetings from Berlin
Robert

#2

Please upload a debug log and post just the token generated by

pihole -d

allowing to upload when prompted, or do it through the Web interface:

Tools > Generate Debug Log

1 Like
#3

Your debug token is: https://tricorder.pi-hole.net/zf1eej71rk

#4

Hello,
any findings in debug log?

#5

Sorry, got busy yesterday and didn't get back to this.

It may be your PHP version. For Buster, it is as follows:

*** [ DIAGNOSING ]: php version
[i] 7.3.19

For your install of Bullseye, it is:

*** [ DIAGNOSING ]: php version
[i] 7.4.14

Slightly different topic, since we don't see many Bullseye debug logs. Our supported OS checker shows this for your Bullseye in the debug log:

*** [ DIAGNOSING ]: Operating system
[i] dig return code:  0
[i] dig response:  "Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8"
[✓] Distro:  Debian
[✗] Version: 
[✗] Error: Debian is supported but version  is currently unsupported (https://docs.pi-hole.net/main/prerequisites/)

How does Bullseye report itself in the OS? Please post the output of the following:

cat /etc/os-release

1 Like
#6

PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="Debian -- Support"
BUG_REPORT_URL="https://bugs.debian.org/"

#7

but would Pi-hole run if PHP 7.4x has caused the problem?
As I wrote before Pi-hole itself runs fine, only webinterface does not work because lighttpd does not start with the phole conf

#8

It would. PHP is just used for the web interface, and this is where you have problems.

Interesting that Bullseye is not reporting a version yet. They may hold this until final release. With Raspbian Buster, the OS is reported as this:

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian

With Armbian Buster, it's:

PRETTY_NAME="Armbian 20.11.6 Buster"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
#9 
sudo /usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf
2021-01-25 02:22:56: configfile.c.461) Warning: "mod_compress" is DEPRECATED and has been replaced with "mod_deflate".  A future release of lighttpd 1.4.x will not contain mod_compress and lighttpd may fail to start up
2021-01-25 02:22:56: plugin.c.195) dlopen() failed for: /usr/lib/lighttpd/mod_deflate.so /usr/lib/lighttpd/mod_deflate.so: cannot open shared object file: No such file or directory
2021-01-25 02:22:56: server.c.1233) loading plugins finally failed

solution:

sudo apt-get install lighttpd-mod-deflate
1 Like
#10

found another problem after reboot:
DNS service not running FTL offline

after executing

sudo pihole -g

DNS and FTL are up and Pi-hole is working again

debug token: brhnx4ws6q

#11

You're running on a testing release of the Debian distribution. I expect things to not work.

Use pihole status instead of the web interface to confirm your reports, it looks like lighttpd is not set up correctly, or just doesn't work, in Bullseye.

#13

/var/www/html/admin/scripts/pi-hole/php/func.php
is "your" script not mine!

I do not run any custom script, only standard setup nothing changed.

Sounds that you are not interested in preparing Pi-hole for Bullseye or why you answering some kine of rude?
It is no problem for me when you are not interested in investigating issues in Bullseye.
I only want to contribute and help to get Pi-hole ready for the next Debian release.

I have a workaround that I can live with.
Sorry for disturbing

PS: please remove my log I don't want to publish it pulic!
for that reason I used the token method

#14

I'm talking about the whitelist script you're running. The one that is calling: sudo pihole restartdns reload which is why your DNS server is down. [2021-01-26 18:24:55.454 22966M] Shutting down...

Or the script that is trying to push out customdns, I highly doubt you typed 5 commands in one second:

   2021-01-25 10:42:57: mod_fastcgi.c.487) FastCGI-stderr:PHP Warning:  Executing sudo pihole -a addcustomdns 192.168.67.23 
   2021-01-25 10:42:57: mod_fastcgi.c.487) FastCGI-stderr:PHP Warning:  Executing sudo pihole -a addcustomdns 192.168.67.111 
   2021-01-25 10:42:57: mod_fastcgi.c.487) FastCGI-stderr:PHP Warning:  Executing sudo pihole -a addcustomdns 192.168.67.112
   2021-01-25 10:42:57: mod_fastcgi.c.487) FastCGI-stderr:PHP Warning:  Executing sudo pihole -a addcustomdns 192.168.77.1
   2021-01-25 10:42:57: mod_fastcgi.c.487) FastCGI-stderr:PHP Warning:  Executing sudo pihole -a addcustomdns 192.168.72.1
   2021-01-25 10:42:57: mod_fastcgi.c.487) FastCGI-stderr:PHP Warning:  Executing sudo pihole -a addcustomdns

No, I'm just tired of people running third party scripts and then blaming Pi-hole when it's user inflicted issues.

If you can replicate this on Bullseye with a stock install that hasn't been screwed with then we'll take a look.

Edit: This is the script you're running: whitelist/scripts at master · anudeepND/whitelist · GitHub

I can tell because that's the data that is being pushed in to the database: whitelist/domains.sql at 46289a50557e1c215a9f022d5e61f31fdc1075c5 · anudeepND/whitelist · GitHub

#15

We are interested in preparing for Bullseye (as we did for Buster, and Stretch before that), but until Bullseye is a stable release there isn't much we can do to reliably prepare.

And even then, we need to test it on clean Pi-hole installs.

#16

you are right about the script but that has run only one time (see timestamp) to import a long whitelist which I was too lazy to type in by hand (yes I cannot type 5 commands in one second). It does not run again and does not run every boot and the problem also exits before the script run one time.

uninstalled (which removes the before added domains from whitelist), but problem persists after removing "the script".

I will setup vanilla Bullseye, install pihole and provide a fresh debug log and you will see the import script is not the reason :wink:

#17

We'll see. Pi-hole without futzing doesn't call sudo pihole restartdns reload so I'd be interested to see where that came from.

#19

I reinstalled pihole and problem went away
used the "evil" import script again and problem did not reoccur

I used teleporter a lot maybe 'sudo pihole restartdns reload' is initiated after restoring config from backup

conclusion: installation was a bit faulty from the beginning when lighttpd-mod-deflate was missing (I didn't run a complete reinstall after I figured that out)

regards Robert

#21

Apology accepted.

1 Like
#22

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.