Spuckt cat /etc/resolv.conf noch immer Cloudflare aus, oder wurde das wieder geändert? Im Fall, wiederhole noch einmal dies:
echo 'nameserver 1.1.1.1' | sudo tee /etc/resolv.conf
Und welchen Netzwerk-Stack nutzt du? Was gibt das aus?
ls -l /etc/resolv.conf
Hallo MichaIng,
Cloudflare war wieder raus, ist jetzt wieder drin.
Das ist das Ergebnis nach den der Eingaben:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ ls -l /etc/resolv.conf
-rw-r--r-- 1 root root 19 22. Feb 18:04 /etc/resolv.conf
KE@Raspberry-Pi-3-Model-B-Plus:~ $ dig -4 +short -t txt versions.pi-hole.net @ns1.pi-hole.net
"Raspbian=11,12 Ubuntu=20,22,23,24 Debian=11,12 Fedora=40,41 CentOS=9"
Danke und Gruß Eggi
Okay, es ist kein symlink. Nutzt du ifupdown?
cat /etc/network/interfaces
Warte aber noch mal mit dem v6 update. Da werden aktuell nicht alle Einstellungen migriert. Aber Grund und Lösung wurden bereits gefunden.
Hallo MichaIng,
ifupdown sagt mir nichts.
Das ist das Ergebnis nach den der Eingaben:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ cat /etc/network/interfaces
source /etc/network/interfaces.d/*
"Warte aber noch mal mit dem v6 update. Da werden aktuell nicht alle Einstellungen migriert. Aber Grund und Lösung wurden bereits gefunden." -> Was meinst Du damit?
Danke und Gruß Eggi
Gibt es was in /etc/network/interfaces.d/? Oder nutzt du dhcpcd?
ls -l /etc/network/interfaces.d/
systemctl status dhcpcd
Wenn ich im Browser "http://192.168.1.5/admin/" aufrufe, erhalte ich eine "403 Forbidden" Fehlermeldung.
Versuch mal https, hat bei mir funktioniert
Noch ist das Update bei ihm jedoch nicht durch.
Diese beiden Pull Requests solltest erst gemerged sein, und ein Pi-hole v6.0.4 released mit denen drin.
In der Zwischenzeit schauen wir weshalb dein DNS zurück auf Pi-hole springt:
ls -l /etc/network/interfaces.d/
systemctl status dhcpcd
Hallo MichaIng,
das ist das Ergebnis nach den der Eingaben:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ ls -l /etc/network/interfaces.d/
insgesamt 0
KE@Raspberry-Pi-3-Model-B-Plus:~ $ systemctl status dhcpcd
● dhcpcd.service - DHCP Client Daemon
Loaded: loaded (/lib/systemd/system/dhcpcd.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2025-02-22 15:07:44 CET; 4h 38min ago
Docs: man:dhcpcd(8)
Main PID: 425 (dhcpcd)
Tasks: 1 (limit: 2057)
CPU: 14.922s
CGroup: /system.slice/dhcpcd.service
└─425 /usr/sbin/dhcpcd -b -q
Feb 22 18:55:41 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:04:56 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:07:40 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:10:19 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:18:02 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:22:40 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:24:50 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:32:37 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:37:40 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
Feb 22 19:39:29 Raspberry-Pi-3-Model-B-Plus dhcpcd[425]: eth0: Router Advertisement from fe80::b2f2:8ff:fe1>
lines 1-20/20 (END)
Danke und Gruß Eggi
Please check /etc/dhcpcd.conf, whether there 127.0.0.1 is defined as DNS.
Hallo MichaIng,
das ist das Ergebnis nach den der Eingaben:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ /etc/dhcpcd.conf
-bash: /etc/dhcpcd.conf: Keine Berechtigung
Mit "https://192.168.1.5/admin/" und einem neu gesetzten Passwort kann ich auf das Pi-hole Webinterface zugreifen.
Ganz unten zeigt er mir "Core v5.18.4 FTL v6.0.1 Web interface v6.0.1" an. Das passt wohl nicht.
Ich habe mal in die Settings geschaut… ich erinnere, dass ich das mal verstanden habe 
Danke und Gruß Eggi
Das ist keine Datei zum Ausführen. Schau mal was drin ist, e.g.
cat /etc/dhcpcd.conf
oder mit einem editor
nano /etc/dhcpcd.conf
EDIT: Pi-hole v6.0.4 mit den obigen Fehlerbehebungen wurde gerade veröffentlicht. Insofern kannst du pihole -up noch mal versuchen. Schau aber vorher mal mit obigen Befehlen, ob dort 127.0.0.1 als DNS server festgelegt ist. Das würde /etc/resolv.conf erklären, da es die Datei ggf. regelmäßig überschreibt.
Hallo MichaIng,
das ist das Ergebnis nach den der Eingaben:
KE@Raspberry-Pi-3-Model-B-Plus:~ $ cat /etc/resolv.conf
nameserver 1.1.1.1
KE@Raspberry-Pi-3-Model-B-Plus:~ $ nano /etc/dhcpcd.conf
KE@Raspberry-Pi-3-Model-B-Plus:~ $ sudo pihole -up
[✓] Supported OS detected
[✓] Update local cache of available packages
[i] Existing PHP installation detected : PHP version 7.4.33
/opt/pihole/update.sh: Zeile 115: build_dependency_package: Kommando nicht gefunden.
Danke und Gruß Eggi
Hey Eggi,
ich habe hier deinen Beitrag gefunden und genau das gleich Problem gehabt.
Bir mir ging nach dem pihole -up nichts mehr, weil direkt von Version 5 auf Version 6 geupgraded wurde, was von mir aus gesehen schon völlig falsch von den Entwicklern gelöst ist.
Sowas dürfte gar nicht möglich sein.
In einem Beitrag habe ich folgendes gefunden:
sudo pihole checkout master
Dieser Befehl holt die richtigen Abhängigkeiten aus dem Git Repository, sodass ein Update bzw. ein Repair funktionieren sollte.
Danach lief wieder alles nur, dass ich PiHole dann per https aufrufen musste.
Heute morgen kam wieder ein Update rein (6.0.4), bei dem lighttpd entfernt wird und danach läuft dieser wieder komischer weise unter http, ohne Secure also.
Ich blicke nicht wirklich durch, was die da gemacht haben, aber die rudern gerade ganz schön, was einerseits gut ist, dass sie so einen Einsatz zeigen aber andererseits finde ich den ganzen Updateprozess, der eigtl. ein völlig vergeigter Upgradeprozess war, sehr unprofessionell.
Ich habe meinen PI-Hole erstmal deaktiviert bis ich irgendwo lese, dass alles nun wieder stabil läuft. War genervt, meine Fritzbox wieder umzukonfigurieren.
Steff
Hier mein Raspi V4 mit folgendem OS:
cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
NAME="Debian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
EDIT:
https geht weiterhin, nur muss hier der Port 8443 mit angegeben werden.
Hier noch ein Link, um die Temperatur Anzeige dargestellt zu bekommen.
Die ist in der neuen Version 6 auch nicht mehr vorhanden.
Hallo Steff,
danke für Deine Unterstützung. Ich werde erstmal mit MichaIng fortfahren, da er mir das Gefühl gibt zu wissen was er tut 
Ich werde aber Deinen Tip weglegen und bevor ich neu installiere auf alle Fälle noch probieren.
Danke und Gruß Eggi
Okay, static domain_name_server=1.1.1.1 sieht gut aus. Dann sollte auch /etc/resolv.conf nun bei 1.1.1.1 bleiben.
Oh, das ist also bereits ein v6 Skript. Dann ist das Update bei dir einmal bereits weiter fortgeschritten als ich dachte. Wichtig ist, dass /etc/.pihole und /opt/pihole auf dem gleichen Stand sind, und da /opt/pihole bereits v6 ist (ich dachte es wäre noch v5), muss /etc/.pihole ebenfalls auf v6 gebracht werden.
Das ist dann tatsächlich eine gute Lösung um alle Repositories auf den v6 Stand zu bringen. Der Befehl holt übrigens keine Abhängigkeiten, sondern synchronisiert die Dateien in /etc/.pihole (und ggf. /var/www/html/admin) mit denen auf dem Server. Entscheidend für pihole -up und pihole -r sind der Installer /etc/.pihole/automated\ install/basic-install.sh, welcher von beiden Befehlen aufgerufen wird, und vorweg einige seiner Funktionen. Oben hat pihole -up versucht build_dependency_package aus dem v6 Installer auszuführen, welches im v5 Installer noch nicht existiert.
Ein pihole -r danach macht ja genau dasselbe wie pihole -up, auch wenn die Repositories bereits auf dem aktuellsten Stand sind. Also noch mal die Kombination für @Eggi:
sudo pihole checkout master
sudo pihole -r
Da ist tatsächlich einiges durcheinander geraten, aber es war auch ein großes Update, mit nicht trivialen Migrationsschritten. Und da der Prozess/die Skripte insgesamt komplex sind, führen kleine Änderungen in A manchmal zu unerwarteten Nebenwirkungen in B. Beispielsweise habe ich beim Testen von frischen v6 Installationen nach dem Release festgestellt, dass das web UI ohne Passwortschutz dasteht, obwohl es dafür extra einen Check gibt, welcher im Falle eines nicht vorhandenen Passworts, ein zufälliges erstellen soll. Der Check hatte jedoch einen Fehler. Also habe ich den Fehler korrigiert, und in Open Source Manier einen Pull Request geöffnet, welcher zusammen mit einer anderen Fehlerkorrektur dann als v6.0.3 veröffentlich wurde. Was ich jedoch beim Testen von frischen Installationen nicht bemerkt habe: diese Korrektur führte zum Auslassen der Migration der alten Konfigurationsdateien bei Updates. Das Erstellen das Passworts, erstellt die neue Konfigurationsdatei, was vor den Migrationsschritten passierte. Die Migration wurde jedoch ausgelassen, sofern die neue Konfigurationsdatei bereits existierte. Inzwischen ist das das mit v6.0.4 behoben.
Dass die Skripte in /etc/.pihole teils nach /opt/pihole kopiert werden, /etc/.pihole bei beim Updateprozess sehr früh auf den aktuellen Stand gebracht wird, /opt/pihole jedoch sehr spät, birgt das Risiko dass beide Seiten verschiedene/inkompatible Versionen beinhalten können, wenn das Update in der Mitte abbricht. Es wäre sicherlich stabiler, wenn die Skripte aus /opt/pihole nicht auf Funktionen aus /etc/.pihole zurückgreifen, also so viel wie möglich vom Installer-Skript selbst erledigt wird, inklusive seines eigenen Updates. Aber das erfordert eine Umstrukturierung die wiederum Fehler mit sich bringen kann und ausgiebig getestet werden muss. Dass mit v6 alle Konfigurationsdateien ein /etc/pihole/pihole.toml zusammengefasst wurden, war eine ähnliche sehr sinnvolle Umstrukturierung, um Fehlerquellen durch Configs in diversen unterschiedlichen Ordnern zu vermeiden. Aber genau diese Migration selbst ist eben auch Fehleranfällig. Selbiges für das Einbetten des Webservers und PHP-Interpreters in pihole-FTL. Schaltet Fehler im Zusammenhang mit separaten Lighttpd und PHP Setups und unterschiedlichen Versionen (je nach Betriebssystem) aus, aber dann muss Pi-hole halt auf andere Ports umsteigen und/oder eine Logik für den Umgang des obsoleten Lighttpd einbauen, die offensichtlich ebenfalls bei einigen nicht ganz wie gewünscht gekappt hat.
Will sagen: Es wurde mit v6 sehr vieles in eine sehr sinnvolle Richtung zusammengefasst, was Pi-hole und seine Updates in Zukunft deutlich einfacher und fehlerfreier machen sollte. Genau solche größeren strukturellen Änderungen sind jedoch immer Fehleranfällig, bei der Vielzahl an Systemen und Setups, welche berücksichtigt werden müssen. Und Pi-hole ist kein kommerzielles Projekt, sondern rein Spendenfinanziert, wo Entwickler üblicherweise nicht ansatzweise für die Entwicklungszeit bezahlt werden können, sondern dies neben einem anderen Job tun. Da ist das Einführen von festen Testläufen aller Aspekte nicht einfach zu organisieren. Bei einem Großen Pi-hole Update (v5 => v6, v6 => v7) macht es also Sinn, ein Backup zu erstellen, und/oder das Update vorher auf einer geklonten Testinstanz zu testen, und Fehler ggf. zu melden. Wenn man dafür keine Zeit hat, ein paar Tage warten, dann sollten die gröbsten Probleme gelöst sein 
.
Übrigens @Steff du betreibst bei dir den Webserver noch aus einem anderen Grund, sodass die Ports 80/443 nicht von Pi-hole genutzt werden können? Der Lighttpd Webserver kann ja ansonsten deinstalliert werden, sodass Pi-hole 80/443 nutzen kann.
Da habe ich ja was zusammengeschrieben ... sorry für den Roman. Einen schönen Wahltag wünsche ich 
.
Danke für die Zusammenfassung. Sehr schön.
Den Lighttpd habe ich deinstalliert. Habe nebenher noch Docker zu laufen. Ich werde mal schauen, dass ich den Pi-Hole evtl. darauf hin migriere. Dann habe ich beim nächsten Update vom Pi-Hole die Möglichkeit, zu einem vorherigen Build zurück zu springen, falls was schief läuft.
Bei mir brach gestern Abend die Panik aus, als alle Geräte im Netzwerk auf einmal keinen Internetzugriff hatten.
Steff
Stimmt, wobei Docker auch seine eigenen Fehlerquellen mitbringt. Meiner Meinung nach war die Docker Lösung vor Pi-hole v6 wertvoll, wegen der verschiedenen externen Abhängigkeiten. Mit Webserver und PHP in pihole-FTL integriert, bin ich jedoch nicht sicher ob es sich insgesamt lohnt. Mit den Abbildern hast du natürlich recht, wobei diese dann auch die Volumes (Configs/Datenbanken) beinhalten müssen. Ansonsten gibt es ja auch andere Lösungen für native System-Backups.
Hurra, Hurra… es lebt wieder
Ich habe wieder per Browser Zugang, Pi-hole funktioniert wieder als DNS, alles ist gut. Ich bin sehr erleichtert und überglücklich. Recht vielen Dank!
Die Versionen werden jetzt auch als aktuell Angezeigt:
Ein ganz großes Danke schön für die Mühen mit dem unwissenden.
Ich werde mich jetzt noch mal mit den Settings auseinandersetzten, dass ist aber eine andere Baustelle.
Danke und Gruß Eggi
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.