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 ...
- Calling
pihole -upcalls/opt/pihole/update.sh. - It sources the old installer to get
getGitFiles. - It detects that the repo is not up-to-date.
- If an update for core is available, it calls
getGitFilesfrom the v5 installer. - That one finally calls
git pull, after which the installer is v6. - Then it calls the new installer (if an update for core is available)
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.