I have an Engenius ens202ext running 18.06.01 from the releases section.
This morning I tried upgrading to 18.06.02 using both LuCI and sysupgrade, with no luck.
The device reboots almost immediately back to 18.06.01.
Here is the output of sysupgrade -v
Have you tried flashing it immediately again after the first failed flash? On my wndr3700v2, flashing fails after some uptime, but doing it after a reboot so far always worked.
On next try, just gracefully stop all active services before sysupgrade, "/etc/init.d/service stop"
And verify, it exited.
Kill all your user processes, if any.
In summary, to have the system as quiet as possible.
And verify, that the new image really works, when flashed directly.
Stopped services, and killed user processes.
After reboot, still showing 18.06.1
Not sure what I need to do to achieve that - could you let me know what I should do, please?
Image metadata not found
Found CHK image with device board_id U12H315T00_NETGEAR
Found a valid TRX version 1
Saving config files...
...
Commencing upgrade. Closing all shell sessions.
A reason, at least. Feel free to confirm the bug report, I filed, with your comments.
Bad idea of sysupgrade to 'forget' such erros, reported from lower level routines.
In such case, no boot should happen, and report of detected error in system log.
17.01.x changed sysupgrade to work in a detached mode, which is safer (reverting into an initramfs like mode, with sysupgrade taking over the init job), but comes at the expense that debug messages aren't visible over ssh anymore (leaving just serial as an option to observe its actions) and that the device must reboot afterwards.
Thank you. I'm not seeing a bug report yet - maybe it takes time to filter through - or (more likely) I'm looking in the wrong place.
We know, thanks to slh reply, that sysupgrade is unable to supply the mtd error to the user over ssh or on-device log.
But I wonder what is next step - would it be to wait for an updated openwrt-18.06.2-bcm53xx-netgear-r8000-squashfs.chk which does not fail the Image check?
Bug report: I mentioned a link up here. Pls, add your observations. Your problem seems to be another manisfestation of the 'silent' errors during sysupgrade, reported nowhere. Which is really dangerous when doing (unattended) remote sysupgrade. The new behaviour, mentioned by slh, seems to be rather buggy and needs serious overhaul.