installer: exit if FTL update check fails#6316
Conversation
18b6f9e to
c010ce6
Compare
The return code of `FTLdetect()` is used in the installer to know whether FTL has been installed or not. The function however returns an error only, if the download of FTL fails, not if checking for a latest version/update of FTL fails. This way, installs and rapairs can continue without or with ourdated FTL until `pihole-FTL migrate v6`, which hangs endlessly, if it is a v5 FTL. This commit handles the return code in `FTLdetect()`, and lets it return true only if FTL download succeeded, or if the update check succeeded and FTL is up-to-date. Else, it could neither be repaired, nor installed, and the error message should give a hint what went wrong, hence exit. `FTLdetect()` is not called by any other script, hence this change has no surprising effect elsewhere. Additionally, a syntax error in the `FTLcheckUpdate()` function itself is fixed, which masks the `check_download_exists()` return code, hence always leads to error code 4, if the FTL branch is not `master`. Signed-off-by: MichaIng <[email protected]>
c010ce6 to
3a35e58
Compare
|
Now I recognized the main problem which causes the forum issue which triggered this PR: https://discourse.pi-hole.net/t/80614
if ! check_download_exists "$path"; then
local status
status=$?masks the return code of |
|
This pull request has been mentioned on Pi-hole Userspace. There might be relevant details there: |
|
Btw, the update script handles the exit codes of the function, prints meaningful error messages (hiding the origin ones, but that makes sense as of update vs install/repair purpose), and exits on uncommon errors. But it continues if the FTL update check returns with 404 on non-master branch, only suggesting to switch to a valid branch: https://github.com/pi-hole/pi-hole/blob/master/advanced/Scripts/update.sh#L157-L177 This can also lead to systems with v6 core/web but v5 FTL, failing at config migration. IMO it makes sense to also abort the update in that case. The updater prints the command to change it, so it is even easier to recognize that issue and fix it, if this message is the last on the console. Or is there a particular reason/need this is currently allowed to continue? |
|
No, it should not be allowed to continue. The base requirement for everything in v6 is for FTL to be v6. There should never be a situation where the core or web repos are v6 while FTL is still v5. If the core/web are v5 and there is no FTL v6 binary installed or available to be installed then there should not be a partial update by moving only core/web to v6. |
Ah so |
Agreed, I opened a PR for this: #6329 |
Thank you for your contribution to the Pi-hole Community!
Please read the comments below to help us consider your Pull Request.
We are all volunteers and completing the process outlined will help us review your commits quicker.
Please make sure you
What does this PR aim to accomplish?:
The return code of
FTLdetect()is used in the installer to know whether FTL has been installed or not.The function however returns an error only, if the download of FTL fails, not if checking for a latest version/update of FTL fails. This way, installs and rapairs can continue without or with ourdated FTL until
pihole-FTL migrate v6, which hangs endlessly, if it is a v5 FTL.How does this PR accomplish the above?:
This commit handles the return code in
FTLdetect(), and lets it return true only if FTL download succeeded, or if the update check succeeded and FTL is up-to-date. Else, it could neither be repaired, nor installed, and the error message should give a hint what went wrong, hence exit.FTLdetect()is not called by any other script, hence this change has no surprising effect elsewhere.Link documentation PRs if any are needed to support this PR:
By submitting this pull request, I confirm the following:
git rebase)