-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate upgradability from historical PiRogue to new ViRogue #21
Comments
For the last point, we could probably try and read some settings (e.g. SSID, PSK, dashboard password) from the current configuration, and use a few |
Let's help support upgrades on existing systems (without pirogue-admin integration): - Tone down the logging from error to warning. - Exit with rc=0 instead of rc=1. Link: #21
That is a prerequisite to supporting upgrades on existing systems (without pirogue-admin integration). Link: PiRogueToolSuite/pirogue-admin#21
Run the autodetection not only when performing a fresh install, but when upgrading existing systems (without pirogue-admin integration) as well. Use the old-version parameter of the postinst to determine when that should happen. [ Best viewed with -b due to indentation changes. ] Link: PiRogueToolSuite/pirogue-admin#21
On a Pi 4, the following remains:
Interfaces we don't want, Cc @U039b: do we want to take the risk of adding a little more code in the upgrade path? (It's a bit of a pain to test as one needs to deploy a system the old way, then upgrade.) Or are we happy to have a tiny section “how to upgrade an historical PiRogue” that explains how to (re)configure? |
Alright, another attempt with updated packages looks great. I've tagged the PPA as Keeping this issue open for the question asked in the previous comment. For completeness, here's the upgrade transcript (that's on a Pi 5):
|
Initially we mentioned we would not try and support upgrades from the historical, PiRogue-based approach to the new
pirogue-admin
/ViRogue-based approach.That would probably mean using different repositories, having the risk of users still pointing to the old/current ones and never getting any upgrades.
It seems feasible to try and support that upgrade in best effort mode, with at least a couple of glitches spotted with a first attempt:
pirogue-ap
andpirogue-networking
have files in common, aConflicts
is needed.debian-12
branch that need to be merged/cherry-picked into thevirogue
one (e.g. indeb-packages
, for thepirogue-archive-keyring
addition).--redeploy
cannot work when existing packages (e.g.pirogue-dashboard
,pirogue-eve-collector
,pirogue-flow-inspector
) get upgraded: the config file is very likely to be missing at this point.pirogue-base.postinst
only does autodetection on initial installation. It should also do it when upgrading from an “historical” version.Quick comments/ideas:
virogue
branch while 1.1.* versions are used in thedebian-12
branch. Version comparison will let us know if we're upgrading from an “historical, PiRogue-based” setup.The text was updated successfully, but these errors were encountered: