Given that the upcoming OpenWRT 20.x move to DSA involves a significant change in config files, ‘network’ specifically, is there any plan to address the sysupgrade process?
I’d assume that it would need to happen during the sysupgrade process, modifying relevant config files to make them compatible with new approaches before the new build boots.
For single user, a start-over approach might be ok, but what about fleets of deployed units all over the place?
Any pointers or ideas welcome.
I would think that this will be done by a "simple" conversion script. If its to complex e. g. new configfile syntax, Applications usually shipping just a new default configfile and you have to start from scratch.
For non-standard applications you have to do this by yourself anyway. Because they will not take care about conversation of those configfiles. But you can preserve them with adding to a list.
Also I can imagine that there is no upgrade path available between major release. And I wouldn't wonder if a full reset is recommended in some cases. Like in past for certain devices.
In general the process is the same as on every sysupgrade. saving old configs in ram or other/free partition. flashing new firmware. writing back old configfiles. on first boot a script will make the necessary changes for new settings.
Excuse me, what does this mean ? I also have a fleet of customized openwrt devices, which are even dynamically reconfigured remotely, from time to time.
Some script likelihood info, I believe there are currently only two targets in master that are impacted. Presumably anyone deploying a fleet would be baking the requisite changes into images generated.
Thanks for your reply, but it leads to another question: is there a way to run a custom script at the point old config files are being written during the sysupgrade sequece?
Since it is the network layer that is affected, I'd think one would wind up with a kernel error or a non-functional network.
If it's just a non-functional network, and my startup-script can run, then it could correct the configs and reboot. But I see many claiming near bricked units on sysupgrade preserving settings.
Platfom is MT7621/7603, in case that matters. The fix-ups we'd need are actually pretty minor in terms of effort.
It means if your devices are MVEBU or MT76-based, then there is a significant change in how the network switch is handled, and requires a change in the /etc/config/network (and possibly other files) to work with the future 20.x builds (or current Master).
The changes are not rocket-science, and ideally could be done during the sysupgrade, if there is a way to run some custom code at the right time.
Or if the change is non-fatal (i.e. the kernel is running) and a startup script can be run, then that script could detect the need for fix-ups and perform them, then reboot.
One could implement a UCI defaults script that greps UCI settings for a LAN bridge for lan1 - lan4, and reconfigure as necessary. However, I reckon devs aren't keen on integrating something like that with all the corner cases.
So if you have some devices you can test that on, that might just work. But you need to be your own tester.
I just wiped the settings in my MT7621 device. Easier to restore other parts of my configuration rather than messing with extra scripts. Then again, I have only one DSA device 'in production' at the moment.
Thank you so much, this is the answer.
I just read up on https://openwrt.org/docs/guide-developer/uci-defaults
And that is how to fix this. So we will bake in a new uci-defaults script in our upcoming build that will check and migrate from 19.07.x to the new DSA requirements in the network and one or two other settings.
Will leave the thread open for a bit to see if there any warnings or other input, but I'l mark your answer as the solution if nothing else pops up.
Glad I could help. Just make sure to test-drive them.
There might be better solutions. That said I would do it like (I don't know if this works; never did it as I make my own builds including this file in ROM):
Another possibility would be to simple run your script before upgrade making your changes in your configfiles (Don't reboot!). Just make your sysupgrade right after. The effect should be the same. Because the files are preserved. Quick and dirty. 
Thanks for both your ideas, either would work, but the mod before upgrade is risky, as we have seen a sysupgrade not take, and now the config would be borked.
Since we do our own builds, easy enough to add some uci-defaults scripts in our 20.x based builds so they can upgrade from 19.x running configs. That seems the most reliable approach, unless I'm missing something.
And yes, testing, lots of it 
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.