This is kinda fresh install, I did it at the end of 2024. Never had this issue before. Updated first DietPi to latest stable v9.10.0 and after that tried to update PiHole. Running unbound. Help is very much appreciated. Not sure what exactly went wrong or what I did incorrectly.
DietPi: v9.10.0
Raspberry Pi 2 Model B
Update got stuck on "Waiting until DNS resolution is available". Here is logs from the update process: PrivateBin
This may happen if your OS isn't aware of a public DNS server.
If that 'Waiting until DNS resolution is available...' shows up for longer during installation, you could try to open another terminal session into your Pi-hole machine and edit /etc/resolv.conf to point to a public nameserver , e.g. nameserver 9.9.9.9.
Shortly after, you should then see the update process continue.
I ran into the same issue when testing the v6 upgrade, intentionally using Pi-hole as its own host's DNS resolver (which I usually do not advise). Let me try again. So Pi-hole v5 uses Cloudflare:
root@VM-Bookworm:~# grep '^server=' /etc/dnsmasq.d/01-pihole.conf
server=1.1.1.1
server=1.0.0.1
Now running the update:
root@VM-Bookworm:~# pihole -up
[✓] Update local cache of available packages
[i] Existing PHP installation detected : PHP version 8.2.26
[✓] Checking for git
[✓] Checking for iproute2
[✓] Checking for dialog
[✓] Checking for ca-certificates
[i] Checking for updates...
[i] Pi-hole Core: update available
[i] Web Interface: update available
[i] FTL: update available
[i] Pi-hole core files out of date, updating local repo.
[✓] Check for existing repository in /etc/.pihole
[i] Update repo in /etc/.pihole...HEAD is now at 0e6d9e7 Pi-hole Core v6.0.2 (#5939)
[✓] Update repo in /etc/.pihole
[i] If you had made any changes in '/etc/.pihole/', they have been stashed using 'git stash'
[i] Pi-hole Web Admin files out of date, updating local repo.
[✓] Check for existing repository in /var/www/html/admin
[i] Update repo in /var/www/html/admin...HEAD is now at 42e7279a Pi-hole web v6.0.1 (#3234)
[✓] Update repo in /var/www/html/admin
[i] If you had made any changes in '/var/www/html/admin/', they have been stashed using 'git stash'
[i] FTL out of date, it will be updated by the installer.
[✓] Root user check
.;;,.
.ccccc:,.
:cccclll:. ..,,
:ccccclll. ;ooodc
'ccll:;ll .oooodc
.;cll.;;looo:.
.. ','.
.',,,,,,'.
.',,,,,,,,,,.
.',,,,,,,,,,,,....
....''',,,,,,,'.......
......... .... .........
.......... ..........
.......... ..........
......... .... .........
........,,,,,,,'......
....',,,,,,,,,,,,.
.',,,,,,,,,'.
.',,,,,,'.
..'''.
[i] SELinux not detected
[✓] Update local cache of available packages
[✓] Checking apt-get for upgraded packages... up to date!
[✓] Building dependency package pihole-meta.deb
[✓] Installing Pi-hole dependency package
[✓] Supported OS detected
[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...
[✓] Detected x86_64 architecture
[✓] Downloading and Installing FTL
[✓] Installing scripts from /etc/.pihole
[i] Installing configs from /etc/.pihole...
[✓] Installing latest Cron script
[i] Installing latest logrotate script...
[i] webserver.log added to logrotate file.
[✓] Installing latest logrotate script
[i] man not installed
[✓] New password set
[i] Testing if systemd-resolved is enabled
[i] Systemd-resolved is not enabled
[i] Upgrading gravity database from version 15 to 16
[i] Upgrading gravity database from version 16 to 17
[i] Upgrading gravity database from version 17 to 18
[i] Upgrading gravity database from version 18 to 19
[i] Restarting services...
[✓] Enabling pihole-FTL service to start on reboot...
[✓] Restarting pihole-FTL service...
[✓] Migrating the list's cache directory to new location
[✓] Deleting existing list cache
[✗] DNS resolution is currently unavailable
[i] Waiting until DNS resolution is available...
Important point is that pihole-FTL is successfully downloaded and started:
root@VM-Bookworm:~# journalctl -u pihole-FTL
...
Feb 22 13:52:59 VM-Bookworm systemd[1]: Stopping pihole-FTL.service - Pi-hole FTL...
Feb 22 13:52:59 VM-Bookworm systemd[1]: pihole-FTL.service: Deactivated successfully.
Feb 22 13:52:59 VM-Bookworm systemd[1]: Stopped pihole-FTL.service - Pi-hole FTL.
Feb 22 13:52:59 VM-Bookworm systemd[1]: pihole-FTL.service: Consumed 13.740s CPU time.
Feb 22 13:53:00 VM-Bookworm systemd[1]: Starting pihole-FTL.service - Pi-hole FTL...
Feb 22 13:53:00 VM-Bookworm systemd[1]: Started pihole-FTL.service - Pi-hole FTL.
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.978 CET [2239M] INFO: ########## FTL started on VM-Bookworm! ##########
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.978 CET [2239M] INFO: FTL branch: master
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.978 CET [2239M] INFO: FTL version: v6.0.2
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.979 CET [2239M] INFO: FTL commit: ac500d5f
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.979 CET [2239M] INFO: FTL date: 2025-02-21 21:48:20 +0000
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.979 CET [2239M] INFO: FTL user: pihole
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.979 CET [2239M] INFO: Compiled for linux/amd64 (compiled on CI) using cc (Alpine 14.2.0) 14.2.0
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.985 CET [2239M] INFO: Wrote config file:
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.985 CET [2239M] INFO: - 152 total entries
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.985 CET [2239M] INFO: - 151 entries are default
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.986 CET [2239M] INFO: - 1 entry is modified
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.986 CET [2239M] INFO: - 0 entries are forced through environment
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.988 CET [2239M] INFO: Parsed config file /etc/pihole/pihole.toml successfully
Feb 22 13:53:00 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.988 CET [2239M] INFO: PID file does not exist or not readable
Feb 22 13:53:48 VM-Bookworm pihole-FTL[2239]: 2025-02-22 13:53:00.988 CET [2239M] INFO: No other running FTL process found.
root@VM-Bookworm:~#
But at this point, the previous upstream DNS has not been migrated yet:
root@VM-Bookworm:~# grep upstreams /etc/pihole/pihole.toml
upstreams = []
... checking the installer, it actually makes sense:
FTL is installed first, then Pi-hole scripts and configs:
The old config migration is done last:
installPihole however calls remove_old_dnsmasq_ftl_configs:
which removes all old config files before they are migrated:
Hence, also when letting the upgrade continue with a echo nameserver 1.1.1.1 > /etc/resolv.conf on a second SSH session, Pi-hole is left without any upstream DNS, and all other configs lost which were aimed to be migrated:
...
[✓] DNS resolution is available
[i] Neutrino emissions detected...
[✓] Preparing new gravity database
[✓] Creating new gravity databases
[✓] Pulling blocklist source list into range
[i] Using libz compression
[i] Target: https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts
[✓] Status: Retrieval successful
[i] List stayed unchanged
[✓] Parsed 127105 exact domains and 0 ABP-style domains (blocking, ignored 0 non-domain entries)
[✓] Building tree
[i] Number of gravity domains: 127105 (127105 unique domains)
[i] Number of exact denied domains: 0
[i] Number of regex denied filters: 0
[i] Number of exact allowed domains: 0
[i] Number of regex allowed filters: 0
[✓] Optimizing database
[✓] Swapping databases
[✓] The old database remains available
[✓] Cleaning up stray matter
[✓] Done.
[i] Web Interface password: QF83z2Lb
[i] This can be changed using 'pihole setpassword'
[i] The install log is located at: /etc/pihole/install.log
[✓] Update complete!
Core version is v6.0.3 (Latest: v6.0.3)
Web version is v6.0.1 (Latest: v6.0.1)
FTL version is v6.0.2 (Latest: v6.0.2)
root@VM-Bookworm:~# pihole-FTL --config dns.upstreams
[]
I'm not sure whether that analysis is correct.
When upgrading from v5, it would be the v5 basic-install.sh that's running, which does not contain those remove_old_ functions.
I do think though that the problem would arise if you'd cancel the current update process and manually restart it.
No, the installer/repo is updated by /opt/pihole/updater.sh, otherwise it would fail attempting to download FTL, like reported here: DNS Auflösung nach Update auf Version 6 nicht mehr möglich
This happens when something is wrong with the repo so that /opt/pihole/updater.sh does not update it before calling the installer. The old installer then tries to download the old FTL binary names, which do not exist in latest release.
But wait, let me just follow the again ...
pihole -up calls /opt/pihole/update.sh.getGitFiles.getGitFiles from the v5 installer.git pull, after which the installer is v6.This makes all sense, of course the new installer needs to be finally called. The only problem is that the old configs are removed, instead of moving them to /etc/pihole/migration_backup_v6 first. It is then attempted later, where they are gone already.
On disk, yes.
But I'd expect the running update.sh script to still execute functions from basic-install.sh as sourced into memory upon invocation.
If that wouldn't happen and remove_old_* would always be called , I'd have a hard time explaining why the update has succeeded for me without a glitch, completely carrying over my settings.
When the new installer is called, the functions are overwritten. I also wonder why this did not show up earlier, probably something has been moved around?
I opened a PR which fixes it: Fix dnsmasq v5 to v6 config migration by MichaIng · Pull Request #5968 · pi-hole/pi-hole · GitHub
But there is another weird thing I want to understand: In my case, with the current core version, the migration is skipped completely, because /etc/pihole/pihole.toml exists already, while it should not exist yet. As if the new pihole-FTL was started, before it should be started. I am still trying to find out what happens there.
EDIT: So on a latest Pi-hole v5, I download the installer from master branch, adjust it to open a subshell before the migration would be done, and make update.sh calling that one instead of the original master branch installer:
root@VM-Bookworm:~# pihole -v
Pi-hole version is v5.18.4 (Latest: v6.0.3)
web version is v5.21 (Latest: v6.0.1)
FTL version is v5.25.2 (Latest: v6.0.2)
curl -sSfO https://raw.githubusercontent.com/pi-hole/pi-hole/master/automated%20install/basic-install.sh
chmod +x basic-install.sh
sed -i '/migrate_dnsmasq_configs()/a\bash' basic-install.sh
sed -i "s|^.*basic-install.sh --reconfigure|$PWD/basic-install.sh --reconfigure|" /opt/pihole/update.sh
pihole -up
Yeah, I did not find it yet, but must be something like that, just not happening always. Is there probably a cron job or something which might call FTL after it has been updated and before the migration is done? I'll retry the update and see whether I can replicate it at some point. But using setupVars.conf as indicated seems to be better.
Btw, the missing DNS resolution is not caused by the dnsmasq config removal, as long as setupVars.conf exists and is migrated. As then the migration applies the PIHOLE_DNS_1 and PIHOLE_DNS_2 from there. That actually is also a problem, since users might have applied more upstream DNS servers (reasonable or not), which is overwritten then? setupVars.conf is migrated after dnsmasq configs. It should be probably the other way round.
On disk, but that doesn't seem to prompt bash to re-read the file contents, at least not in my tests:
cat test.sh
#!/usr/bin/env bash
source "print-hello.sh"
let "number = 0"
while [[ $number -ne 1 ]]; do
read -ep 'Enter 1 to exit, 5 to change print-hello.sh: ' number
hello
if [[ $number == 5 ]];
then sed -i -e 's/Hello/Bye/' print-hello.sh
fi
done
echo -n
$ cat print-hello.sh
#!/usr/bin/env bash
hello(){
echo -n "Hello: "
echo -n
}
I think there might be a call to pihole-FTL to check the config value of something before we get to the migrate step somewhere....
However - I've got an idea that perhaps instead of using the existence of pihole.toml to decide if we should exit the migration function, we should use the non existence of setupvars.conf
The new installer defines the new functions, in memory. Try to create two scripts, both defining hello() with different output. Source the one first, then call the other one. You will see the output of the other one, of course.
pihole-FTL --config webserver.api.pwhash to check whether there is no password applies. But why is this not creating pihole-FTL.toml when calling the local debug instance of the installer? I do not see [✓] New password set either with that one. But I just tried it again without modification, and then no [✓] New password set, and no problem. So it must be that call, but I have no idea why it is not called when downloading the master branch script and patching it to debug 
.
EDIT: Another test:
curl -sSfO https://raw.githubusercontent.com/pi-hole/pi-hole/master/automated%20install/basic-install.sh
chmod +x basic-install.sh
sed -i '/pw=""/a\bash || :' basic-install.sh
sed -i '/migrate_dnsmasq_configs()/a\bash || :' basic-install.sh
sed -i "s|^.*basic-install.sh --reconfigure|$PWD/basic-install.sh --reconfigure|" /opt/pihole/update.sh
pihole -up
On the first halt point, I called pihole-FTL --config webserver.api.pwhash, which does return nothing, as expected. But also no pihole-FTL.toml is created. Ahh, now hence pihole setpassword ... should be called, in which case pihole.toml of course is created to store this new password with the new FTL. ... at least sometimes, weirdly on my test again that new password is again not created, as if [[ -z $(pihole-FTL --config webserver.api.pwhash) ]] is not true. Checking that one again ...
First debug point, all as expected, no password, hence that should now be created
root@VM-Bookworm:~# [[ -z $(pihole-FTL --config webserver.api.pwhash) ]] && echo empty
empty
root@VM-Bookworm:~# pihole-FTL --config webserver.api.pwhash
root@VM-Bookworm:~# l /etc/pihole/pihole.toml
ls: cannot access '/etc/pihole/pihole.toml': No such file or directory
Yeah, now it was:
root@VM-Bookworm:~# exit
exit
[✓] New password set
2nd debug point hence has pihole.toml, and in turn no migration done:
root@VM-Bookworm:~# l /etc/pihole/pihole.toml
-rw-r--r-- 1 pihole pihole 51K Feb 22 17:22 /etc/pihole/pihole.toml
root@VM-Bookworm:~# exit
exit
[i] Testing if systemd-resolved is enabled
[i] Systemd-resolved is not enabled
...
No idea why, but sometimes [[ -z $(pihole-FTL --config webserver.api.pwhash) ]] seems to be false .
But anyway:
dnsmasq config files must not be removed before the migration => Fix dnsmasq v5 to v6 config migration by MichaIng · Pull Request #5968 · pi-hole/pi-hole · GitHubsetupVars.conf should be migrated, and dnsmasq config afterwards, since the latter contain the true effective settings.pihole.toml is not created before it should. Also, the migration does migrate the web UI password, hence before that, it is only logic that there is no password yet.setupVars.conf is the better indicator that a migration is still needed, as is is moved by FTL as part of the migration command => Only run migration code if setupVars.conf exists. by PromoFaux · Pull Request #5969 · pi-hole/pi-hole · GitHubOkay now I found out about the inconsistency. This PR fixed it as well in another way: Don't set a random password on v5 -> v6 updates by yubiuser · Pull Request #5960 · pi-hole/pi-hole · GitHub
And Fix dnsmasq v5 to v6 config migration by MichaIng · Pull Request #5968 · pi-hole/pi-hole · GitHub contains this already. However, still safer to trust the setupVars.conf than the presence of pihole.toml as indicator for a finished migration. The latter could be created by any intended or unintended FTL call or startup.
And @Bucking_Horn the issue did not appear that obviously before, since setupVars.conf is not removed by remove_old_dnsmasq_ftl_configs, and upstream DNS migrated from there. But some other settings are lost, or when upstream DNS was changed via web UI (which is then not stored back into setupVars.conf, is it?). So overall the reported issues are mostly due to the created pihole.toml and in turn skipped migration, while the removed config files would be recognised only by those who changed settings present only in the removed dnsmasq configs. And since my PR contains #5960, which fixed the skipped migration, it looked my PR solved both, while it fixes only the second part 
.
And the skipped migration did not happen before this: Fix empty password detection by MichaIng · Pull Request #5935 · pi-hole/pi-hole · GitHub 
. I did test this with fresh installs, and hence did not recognize that this fix caused another issue for v5 => v6 migrations, due to the problematic FTL call at this point.
I did like you said and changed it and run update again, which got finished quite quickly. After that I was not able to access Pihole interface It says that "/admin/login.php" File not found.
I reverted the name server settings in /etc/resolv.conf and still nothing is working. Any idea what I am doing wrong?
P.S Nevermind the login URL changed to https://x.x.x.x/admin/login
and don't forget to set back 127.0.0.1#5335 as the Custom DNS for unbound.