<div dir="auto">Hi Rafał,<br>
<br>
On Sun, Sep 1, 2019 at 5:09 AM Rafał Miłecki <<a href="mailto:zajec5@gmail.com" rel="noreferrer noreferrer" target="_blank">zajec5@gmail.com</a>> wrote:<br>
> On Sun, 1 Sep 2019 at 06:13, Reiner Karlsberg <<a href="mailto:karlsberg@softart-ge.com" rel="noreferrer noreferrer" target="_blank">karlsberg@softart-ge.com</a>> wrote:<br>
> > This needs to be handled very carefully, not to break<br>
> > actual usage of -F.<br>
> > I had to use -F couple of times, usually when downgrading<br>
> > installed firmware, but with change of name over time.<br>
> > Typical example: Change of image name for the zbt-we826.<br>
> > Never any problem with usage of -F, though.<br>
> ><br>
> > But I had several problems with non-completion of<br>
> > valid sysupgrade, which even left the system in inconsistent state,<br>
> > as the "-f keep.tar.gz" was applied, but not the new image itself.<br>
> > Or (silently ?) no sysupgrade done, because of mounted block device<br>
> > or active swap file on block device, or active wifi (?).<br>
> > Which was a PITA on remote installations.<br>
> ><br>
> > Question: How are sysupgrade-errors reported/to be handled, as usually also a failed sysupgrade<br>
> > triggered a reboot ?<br>
> > documentation very unclear here, as it looks like, behaviour in case of errro changed during versions of openwrt.<br>
> ><br>
> > Best would be "atomic sysupgrade", with standard error-code (+1) on exit instead of expected reboot after success.<br>
> ><br>
> > I appreciate the new work on sysupgrade, but I am a bit afraid of regressions.<br>
><br>
> No behavior will change until you explicitly modify your target's<br>
> /lib/upgrade/platform.sh to start calling notify_firmware_broken() for<br>
> whatever reason (e.g. unrecognized firmware image format).<br>
><br>
> I'm planning to implement more verbose sysupgrade results later. I was<br>
> thinking about ubus method replying with a JSON containing error code<br>
> and message. I should prepare some patch for that in a next week or<br>
> two.<br>
<br>
Since you're improving sysupgrade to reject some images, I'm throwing an idea I had some time ago (no code, sorry).<br>
<br>
I would be great if there is support for certain sysupgrade images to require a settings reset (without preserving them).<br>
The idea is to support some use cases were preserving the settings might leave the device in a sofbrick / misconfigured state. So a reset to defaults is mandatory, like the recent situation when migrating a configuration from swconfig to DSA.<br>
Sure, it could be done by migrations scripts, but they might not be 100% reliable (cover all possible variations).<br>
<br>
On the implementation side, it could be done using image metadata to store an integer with the minimum version required, which could be used by sysupgrade to compare the locally stored value and check if a reset is mandatory or not.<br>
(this is just one possible implementation)<br>
<br>
Of course, an implementation would not be useful for the current issue of swconfig->DSA, but it might be useful in the future (who knows what might break).<br>
<br>
Regards,<br>
Luis Araneda.<br></div>