I see that the LuCI GUI for flashing firmware has changed between 18.06 and 19.07. Two questions:
The "Keep Settings" checkbox is no longer present. Is there an equivalent facility in 19.07? (Actually, you should always make a backup before flashing firmware...)
There was some discussion about saving and restoring the list of installed packages on the list/in the wiki. Is there an equivalent facility in 19.07?
Thanks.
I'd also like to know.. how to keep 19.07 settings if sysupgrading in the future?
No changes to opkg, and no such scripts automatically included. Info in wiki should still be valid if it worked with 18.06 and master.
I see that now, but I don't think it's a good change to the user experience.
It's pretty late in the sysupgrade process. The newcomer has to "make the leap of faith" and initiate the upgrade before they get a chance to wonder, "Oh wait, am I going to lose all my configuration?" (I wasn't worried because I always make a backup of my settings before upgrading...)
The next time we visit this code, I would ask that we consider:
Thanks.
"Keep settings" availability now depends on the image being uploaded. If the uploaded images does not support it, the facility will be disabled, hence the move to a later stage in the sysupgrade process.
It's not my goal to be contentious (and I certainly don't mean to pick on @jow), but this feels like a significant change to the OpenWrt user experience without a lot of notice. (For the last 7+ years, the "Keep Settings" checkbox has always been present for the routers I used...)
I would be interested to get a more detailed explanation for the reasoning behind the decision:
And more importantly, how do we go forward? 19.07 has shipped - it's done/complete/history. But what do we want to do for future releases? (See, for example, the four points in my earlier message that seem important as we look to simplify/improve the OpenWrt user experience...)
Maybe we can look for a way to preserve both settings and packages as a one-step operation during sysupgrade. Thanks.
I can only speculate -- I'm not on the dev team and I don't have any specific knowledge about the decision.
Consider that there are risks associated with keeping settings across the ar71xx to ath79 targets -- incompatible configuration files could render the devices practically dead, at least for less experienced users.
That said, I would wager that this was a very carefully considered change and that it is intended to keep users from bricking their devices. Although bad configurations will rarely hard-brick the unit, incompatible settings could render the device practically useless and difficult (if not impossible) to recover without significant additional effort, knowledge, and sometimes extra equipment (like USB to serial adapters, soldering tools, etc.). Instead of taking a potentially significant risk, having the device come up in a known good default state is the safest option, and it is often not difficult to reconfigure a router.
The user can, and should, make a backup before any upgrade operation. Those files can be used as reference when reconfiguring, or if deemed safe, can be copied directly back into the router (for those with more complex configurations, they likely have enough knowledge to restore necessary files manually).
I personally would rather deal with a little inconvenience when upgrading in certain circumstances than to have the entire OpenWrt project present high-risk upgrade paths, especially for novice/new users on the platform. That's just my opinion, though.
EDIT: I should add that I actually personally never keep the settings when I upgrade. This way I know the system is coming up fresh in a known good state and I can restore all my stuff in a matter of a few minutes.
The way I see this working is... sysupgrade -k is pretty much default... but some metadata would need to be retained to facilitate proper operation... namely;
Then if the list(s) are detected in a backup file... or it's separately moved during sysupgrade... the a "NEW" page or tab or notice becomes available in luci ( and additionally some manual switches for sysupgrade (or a seperate script - sysupgrade is getting large and complicated ) restore to apply via the command line )...
The user is then able to fairly easily re-apply/install the previous packages...
The reason for not actioning anything is pretty self explanatory... extroot may not be setup yet... and some packages may be required before this... and after this... The second reason is the obvious user interaction to establish the base network connectivity required for opkg to operate... Automation of the opkg install actions ( on next wan connect etc. ) is fairly tricky and it's likely best avoided in the short term.
the UI pkg-restore dropdown would be something like;
Perhaps list checkboxes per dest might be an option here too...
The finer details are all open to interpretation... but I think some of the above would facilitate much of what is needed... Particularly the detailed package location in the dump... and the logic to restore based on this...
It may be the case that overlay-extroot or opkg itself can benefit from some modifications to repond / interact with sysupgrade as a first point of call. ( i.e. the allowances and logic for this are all currently interpolated within sysupgrade... which makes logic a challenge )...
However it is done... I'd love to see a box after sysupgrade the says "Click to re-setup extroot"... you plug in your stick... and it does the setup and install of previous packages for you... ( where possible with most of the functions/logic is shell utility as it's luci independent )
