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

Rafał Miłecki zajec5 at gmail.com
Sun Sep 1 05:09:10 EDT 2019

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

Please use "Reply to all", I almost missed your reply.

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list