[OpenWrt-Devel] Atomic/failsafe upgrades?

[Luiz Angelo Daros de Luca]

Hi,

I have a client that just asked for this. As their router uses grub, its
script if enough for the fallback logic. I implemented a POC and it worked
perfectly. There is no watchdog integration so the reboot is manually done
when the new firmware fails.

I'm just waiting for them to give me a go in order to implement a complete
solution. I'll post to the list when I get a working patch.

The basic idea is to have two rootfs (and two rootfs data) in flash. I
embed the kernel into squashfs, making rootfs self contained (as grub2 can
read squashfs). If I give to sysupgrade a squashfs image, it writes
alternately into the rootfs areas. It tries to boot the new flash once
(like grub-once). If it works, mark it as permanent. If not, just reboot
and the previous flash will be used.

Now, when I give a full xxx.img file, it overwrite all the system just like
the normal openwrt image does (something like proprietary xxx_boot.img). Of
course, this type of boot firmware does not have the fallback.

Regards,

Em qui, 7 de jan de 2016 18:16, Arthur Davis <silpertan at gmail.com> escreveu:

> With failsafe upgrades, there always has to be "the thing that notices"
> when something goes wrong. With a wholesale upgrade, OpenWrt can't be that
> thing. The bootloader is probably the best candidate.
>
> Also, I've worked on projects that used a separate supervisory processor
> that was able to dictate the boot image. In one case, it was a very
> powerful processor that had its own jobs in the system. In another case, it
> was very small and just watched out for system health. One way to dictate
> the boot image is to have the OpenWrt system ask via tftp, but there are
> probably other possibilities depending on your system. (And this probably
> doesn't really apply unless you are able to specify some fundamental bits
> of the hardware.)
>
> Lastly, there is OpenWrt's failsafe mode which doesn't solve all of your
> concerns, but it should be noted:
>     https://wiki.openwrt.org/doc/howto/generic.failsafe
>
> Arthur
>
>
> On Thu, Jan 7, 2016 at 11:48 AM, Eric Schultz <eschultz at prplfoundation.org
> > wrote:
>
>> Joshua,
>>
>> I've had some similar interest in this topic.  As far as I know, there
>> isn't anything like this on OpenWrt. There might be some overlap with the
>> discussion of automatic updates from last week as well.
>>
>> Eric
>>
>> On Thu, Jan 7, 2016 at 11:44 AM, Joshua Judson Rosen <
>> jrosen at harvestai.com> wrote:
>>
>>> I'm trying to decide on a Linux-based OS to use in a project,
>>> and one of the features that I want is failsafe upgrades--
>>> such that failing to run an upgrade procedure to completion
>>> should be non-catastrophic, and automatically recoverable; the
>>> system should always be able to (re)boot into a state
>>> where it can run normally, either in the upgraded state
>>> or in the pre-upgrade state.
>>>
>>> One option that I've deal with is to keep two parallel
>>> system installs, upgrade whichever one you're not currently using,
>>> try to boot _that one_ after the upgrade finishes,
>>> and fall back to the last-known-good install
>>> if either the upgrade fails in the middle or the boot into
>>> the preferred install fails. IIRC, there's something like this
>>> available with Yocto; and, if I understand it correctly,
>>> NixOS also does something similar in spirit to this
>>> (though perhaps with a different granularity).
>>>
>>> Are there any provisions for doing something like that
>>> with OpenWRT?
>>>
>>> --
>>> "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>
>>
>>
>>
>> --
>> Eric Schultz, Community Manager, prpl Foundation
>> http://www.prplfoundation.org
>> eschultz at prplfoundation.org
>> cell: 920-539-0404
>> skype: ericschultzwi
>> @EricPrpl
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
>>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
-- 

Luiz Angelo Daros de Luca
luizluca at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20160108/55ba0f22/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel