On Tue, 3 Sep 2019 at 18:57, Luis Araneda <[email protected]> wrote: > On Sun, Sep 1, 2019 at 5:09 AM Rafał Miłecki <[email protected]> wrote: > > On Sun, 1 Sep 2019 at 06:13, Reiner Karlsberg <[email protected]> > > wrote: > > > This needs to be handled very carefully, not to break > > > actual usage of -F. > > > I had to use -F couple of times, usually when downgrading > > > installed firmware, but with change of name over time. > > > Typical example: Change of image name for the zbt-we826. > > > Never any problem with usage of -F, though. > > > > > > But I had several problems with non-completion of > > > valid sysupgrade, which even left the system in inconsistent state, > > > as the "-f keep.tar.gz" was applied, but not the new image itself. > > > Or (silently ?) no sysupgrade done, because of mounted block device > > > or active swap file on block device, or active wifi (?). > > > Which was a PITA on remote installations. > > > > > > Question: How are sysupgrade-errors reported/to be handled, as usually > > > also a failed sysupgrade > > > triggered a reboot ? > > > documentation very unclear here, as it looks like, behaviour in case of > > > errro changed during versions of openwrt. > > > > > > Best would be "atomic sysupgrade", with standard error-code (+1) on exit > > > instead of expected reboot after success. > > > > > > I appreciate the new work on sysupgrade, but I am a bit afraid of > > > regressions. > > > > No behavior will change until you explicitly modify your target's > > /lib/upgrade/platform.sh to start calling notify_firmware_broken() for > > whatever reason (e.g. unrecognized firmware image format). > > > > I'm planning to implement more verbose sysupgrade results later. I was > > thinking about ubus method replying with a JSON containing error code > > and message. I should prepare some patch for that in a next week or > > two. > > Since you're improving sysupgrade to reject some images, I'm throwing an idea > I had some time ago (no code, sorry). > > I would be great if there is support for certain sysupgrade images to require > a settings reset (without preserving them). > 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. > Sure, it could be done by migrations scripts, but they might not be 100% > reliable (cover all possible variations). > > 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. > (this is just one possible implementation) > > 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).
I see some use-cases for that. I'll implement that. -- Rafał _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
