On Wed, May 13, 2020 at 12:29 PM Michael Jones <m...@meshplusplus.com> wrote:
> > > On Wed, May 13, 2020 at 3:58 AM Jo-Philipp Wich <j...@mein.io> wrote: > >> Hi, >> >> > Stuff like umounting external disks, fsync / swapoff etc. come to mind as >> well >> which should be doable at this point. >> >> >> > Right, that's also feasible. > > In fact I don't see any code at all for unmounting existing filesystem > mounts. Thanks for pointing that out. > I think that it's also reasonable to have /sbin/upgraded, in its role as PID1, have some kind of safety valve on when the upgrade has failed. E.g. if /lib/upgrade/script2 has returned, at all, the system needs to reboot, because at this point /sbin/upgraded should be the only process running. if /lib/upgrade/script2 has not returned after 1 hour, there's no chance that the upgrade will succeed, so reboot. In both situations, the board may be in a bad state. But there's nothing that can be done. /sbin/upgraded offers the user no CLI interactions at all, so there's no recovery actions that could be taken even if there was a UART / Serial / VGA + Keyboard connection to the board to allow user interaction.
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
