Be more graceful when detecting a v5->v6 migration #1629
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PromoFaux
force-pushed
the
v6/migrate-v5-checks
branch
from
ed0343f
to
5a9e670
Compare
* Only start tailing pihole-FTL log from most recent pihole-FTL start * If v5 config files are detected, but no v6 files are, then we must defer some of the configuration until after FTL has migrated the files * move some of the logic from start into bash_functions to make it easier to follow the start Signed-off-by: Adam Warner <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR aim to accomplish?:
So far in development of the v6 container, I've not actually tested any v5->v6 migrations, and rather naively assumed that FTL handled everything we needed to worry about.
In pi-hole/pi-hole#5635, we see that this can cause some issues with
setupVarsnot being correctly migrated by pihole-FTL due to the way we have effectively been bulldozering over that process.This PR adds a check right at the beginning of the startup to determine if we are v5 (Simple check,
if setupVars exists and pihole.toml does not), if we are, then we defer some of the functionality that would write topihole.tomluntil after FTL has first started... giving it a chance to complete it's migrationsOutput after first start when upgrading from v5
Subsequent container starts
Startup on fresh V6 container (no volumes/empty volumes)
By submitting this pull request, I confirm the following:
git rebase)