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. Please use "Reply to all", I almost missed your reply. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
