[OpenWrt-Devel] [PATCH procd] system: reject sysupgrade of broken firmware images

[Luis Araneda]

Hi Rafał,

On Sun, Sep 1, 2019 at 5:09 AM Rafał Miłecki <zajec5 at gmail.com> wrote:
> On Sun, 1 Sep 2019 at 06:13, Reiner Karlsberg <karlsberg at softart-ge.com>
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).

Regards,
Luis Araneda.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190903/7adc2b19/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel