where is the .swu file stored?

[ya...@ieee.org]

when using a web-based download of the .swu file, where is
the .swu stored? On the initrd/rootfs? if so, doesn't that mean the
file size is limited to the RAM size?

[Stefano Babic]

Hi Yats,

On 27/07/2018 01:49, ya...@ieee.org wrote:
> when using a web-based download of the .swu file, where is
> the .swu stored? On the initrd/rootfs?

It is *not* stored. SWUpdate supports streaming - if you activate it.
Check for "installed-directly" flag in the documentation.

If not activated, SWUpdate will extract the required components in
TMPDIR. A project can decide if all components should be extracted
before installing (but then it must has enough resources to store them)
or install them by streaming (but if something is wrong the old software
cannot be started again).

> if so, doesn't that mean the
> file size is limited to the RAM size?

No, see above.

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[ya...@ieee.org]

On Friday, July 27, 2018 at 2:49:19 AM UTC-4, Stefano Babic wrote:
> Hi Yats,
>
> On 27/07/2018 01:49, ya...@ieee.org wrote:
> > when using a web-based download of the .swu file, where is
> > the .swu stored? On the initrd/rootfs?
>
> It is *not* stored. SWUpdate supports streaming - if you activate it.
> Check for "installed-directly" flag in the documentation.

OK, thanks - I hadn't see that option.

So now that brings up another question: if there is a pre-install script, does that mean the "scripts:" section of the sw-description file has to come before the image section? Or does the .swu build order the pieces inside the .swu file automatically?

Similar idea for the post-install script.

--Randy

[Stefano Babic]

Hi Randy,

On 27/07/2018 14:46, ya...@ieee.org wrote:
> On Friday, July 27, 2018 at 2:49:19 AM UTC-4, Stefano Babic wrote:
>> Hi Yats,
>>
>> On 27/07/2018 01:49, ya...@ieee.org wrote:
>>> when using a web-based download of the .swu file, where is
>>> the .swu stored? On the initrd/rootfs?
>>
>> It is *not* stored. SWUpdate supports streaming - if you activate it.
>> Check for "installed-directly" flag in the documentation.
>
> OK, thanks - I hadn't see that option.
>
> So now that brings up another question: if there is a pre-install script, does that mean the "scripts:" section of the sw-description file has to come before the image section?

Search for "embedded script". The script must be embedded in
sw-description and it runs at parsing time before installing anything.

See an example at:

https://github.com/sbabic/meta-swupdate-boards/blob/master/recipes-extended/images/update-image/raspberrypi3/sw-description.embscript

> Or does the .swu build order the pieces inside the .swu file
automatically?

It cannot be sorted automatically when the SWU is streamed. That
requires rules how to build the SWU (first scripts, then images, ..) and
this is bad. There is no constraint how the SWU is built.

>
> Similar idea for the post-install script.

post install scripts run after all files in the section "images" and
"files" were installed.

[ya...@ieee.org]

Thank you. Things are becoming much clearer. Again another question, Stefano.

When using the mongoose streaming option, for a single-copy update, this requires mongoose to be running in the update-boot mode (i.e., using the trimmed linux kernel and the initrd rootfs). But the update process would be initiated with the system in the normal boot mode, e.g., via the GUI.

So how would the procedure work? Would the user first initiate the update in normal boot mode with the GUI, then reboot, then watch the GUI to determine when the system is rebooted into update-boot mode and mongoose is listening, then connect with a web browser on the user's computing device (e.g., laptop)?

Seems a little unwieldy, but it could be done this way. I am just wondering what you had in mind on how to use the mongoose streaming mode.

[Stefano Babic]

Hall Randy,

On 27/07/2018 16:46, ya...@ieee.org wrote:
> Thank you. Things are becoming much clearer. Again another question, Stefano.
>
> When using the mongoose streaming option, for a single-copy update, this requires mongoose to be running in the update-boot mode (i.e., using the trimmed linux kernel and the initrd rootfs). But the update process would be initiated with the system in the normal boot mode, e.g., via the GUI.
>
> So how would the procedure work? Would the user first initiate the update in normal boot mode with the GUI, then reboot, then watch the GUI to determine when the system is rebooted into update-boot mode and mongoose is listening, then connect with a web browser on the user's computing device (e.g., laptop)?

There is *not* a single way to do this - it depends on your requirements
and on your update concept. Anyway, this is a way to do. The normal boot
mode can trigger an update setting the U-Boot variable "recovery_status"
- this must checked by U-Boot to restart a unsuccessful update.

recovery_status is cleared by SWUpdate after a successful update.

>
> Seems a little unwieldy, but it could be done this way. I am just wondering what you had in mind on how to use the mongoose streaming mode.
>