Just to clarify, this basic-install.sh script gets called when doing a "pihole -up" as well as a fresh install?
Yes, that is a tricky bit... I haven't used it in conjunction w/ the pihole script... (ie. not by pihole -up).
Just for install (fresh install)... there is a dialog during install that asks you to choose either install or reconfigure... IIRC... I've tried it w/ both.
OK, I grabbed a copy of basic-install.sh from the unsupported/binary branch and applied the patch to it, then ran "pihole -up". This is the result:
root@pihole:~# PIHOLE_SKIP_OS_CHECK=true PIHOLE_SKIP_FTL_CHECK=true /usr/local/bin/pihole -up
[i] PIHOLE_SKIP_OS_CHECK env variable set to true - installer will continue
[✓] Update local cache of available packages
[✓] Building dependency package pihole-meta.deb
[✓] Installing Pi-hole dependency package
[i] Checking for updates...
[i] Pi-hole Core: up to date
[i] Web Interface: up to date
[i] FTL: update available
[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
[i] PIHOLE_SKIP_OS_CHECK env variable set to true - installer will continue
[i] PIHOLE_SKIP_FTL_CHECK env variable set to true - skipping processor check
[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] PIHOLE_SKIP_FTL_CHECK env variable set to true - skipping FTL binary check
[✓] Installing scripts from /etc/.pihole
[i] Installing configs from /etc/.pihole...
[✓] Installing latest Cron script
[i] Installing latest logrotate script...
[i] Existing logrotate file found. No changes made.
[✓] man pages installed and database updated
[i] Testing if systemd-resolved is enabled
[i] Systemd-resolved is not enabled
[i] Restarting services...
[✓] Enabling pihole-FTL service to start on reboot...
[✓] Restarting pihole-FTL service...
[✓] Deleting existing list cache
[✓] 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: No changes detected
[✓] Parsed 129349 exact domains and 0 ABP-style domains (blocking, ignored 0 non-domain entries)
[i] Target: http://sysctl.org/cameleon/hosts
[✓] Status: No changes detected
[✓] Parsed 20561 exact domains and 0 ABP-style domains (blocking, ignored 0 non-domain entries)
[i] Target: https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt
[✓] Status: No changes detected
[✓] Parsed 34 exact domains and 0 ABP-style domains (blocking, ignored 0 non-domain entries)
[i] Target: https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt
[✓] Status: No changes detected
[✓] Parsed 2701 exact domains and 0 ABP-style domains (blocking, ignored 0 non-domain entries)
[i] Target: https://blocklistproject.github.io/Lists/ads.txt
[✓] Status: No changes detected
[✓] Parsed 154554 exact domains and 0 ABP-style domains (blocking, ignored 0 non-domain entries)
[✓] Building tree
[i] Number of gravity domains: 307199 (266234 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] The install log is located at: /etc/pihole/install.log
[✓] Update complete!
Core version is v6.0.4 (Latest: v6.0.4)
Web version is v6.0.1 (Latest: v6.0.1)
FTL version is v6.0.3 (Latest: v6.0.3)
root@pihole:~#
So it says "FTL out of date, it will be updated by the installer", but the installer then does bypass any actual updates to FTL, so that's good.
Might be better if update.sh just said "Not checked" for FTL, but that would mean tweaking another script, so I'm also fine with it as is.
OK, that is at least a bit of progress, so thank you for posting that back and providing the output.
This particular line is created by the pihole script itself, not the basic-install.sh script. So that won't be addressed in this patch. That would required a change the to pihole script itself.
Actually, the two lines here in your output (in green text on your terminal screen):
... at least let you know that it is skipping the checks in the installer... I added those in for sanity.
My own method of updating the pi-hole instance now is currently:
- build (cross/qemu)
pihole-FTLon my Debian desktop from most recent source, usescpto copy it to/usr/bin - update web portion with
pihole checkout web master - update core portion with
pihole checkout core unsupported/binary
Of course, you have to keep a copy of the patched basic-install.sh script and copy into position at /etc/.pihole/automated install/ when you want it to be called by other scripts... and then it is likely to be overwritten.
If this it incorporated into the repo (even the branch) rather than one of our own (local) forks, then it will be a more durable fix (and not be overwritten).
It would be reasonably easy to script one's desktop Debian (using qemu) or even a 248MB Pogoplug V2 (native compile) to check source, and build the new pihole-FTL during the wee hours of the morning... and maybe even scp a time-stamped copy of the binary into /usr/bin/ for one to inspect an then use as the FTL binary.
By the way, this was on a Pogoplug V4 running Debian 12.9
1 Like
This is pushed to the unsupported/binary branch now at unsupported/binary , so that will make things easier for anyone w/ too old or too new hardware...
Cool. This is going to eventually make it to the master repository, right?
1 Like
Maybe, eventually. At least it is in git, so we (anyone w/ unsupported hw) can pull it when needed.
And a mistake should be addressed... in this post Building Pi-hole v6.0 on Pogoplug V2 - #6 by davygravy
I mention copying over the binary w/ it version tag as part of its filename. That is certainly OK, but then using a symlink w/ link name pihole-FTL is a not a good idea. It causes some problems... I had noticed it right after I posted but got sidetracked and never followed through, until now.
So just copying it from its tagged filename to pihole-FTL is the way to go.
Just as a reference/bookend - pihole-FTL-armv5te : just for pogoplug/*plug machines, armel/armv5te architecture
I’ve put together an autobuilder to check for new git tags/versions of pihole-FTL at the official github repository… and to build, test and upload the binary for the new release …
You’ll still have to do use the regular installer from the unsupported/binary branch, but ARMV5TE/pogoplug users won’t have to roll their own bins.