Make swupdate service recheck sw-versions file before update by swupdate-client?

[Armen]

I am using swupdate 2019.11 to do software updates for our embedded system. We have implemented version check feature where swupdate will only update components that have mismatch in versions reported by the hardware (in /etc/sw-versions) and in the new .swu package.

However, it seems like swupdate only reads this sw-versions file into memory during start up process of swupdate server (swupdate.service) - using method: read_sw_version_file.

While our system is online, we may perform manual updates (not using swupdate) or hot-swap compoments. This will result in versions running on the hardware being different from what is stored in sw-versions copied from last swupdate upgrade.

To resolve this problem, we perform update of sw-versions file before each new swupdate call (using swupdate-client). This way we populate sw-versions with real-time versions information on the HW. However, when we run swupdate-client, the updated sw-versions file is never checked. swupdate is using value that were previously loaded into memory at boot up of the hardware.

How do I fix this problem? Is there something in swupdate that can trigger execution of read_sw_version_file method? Besides forcing swupdate.service to restart, is there anything I can do in pre-install scripts I do not want to restart system.

[Stefano Babic]

Hi Armen,

On 06.06.24 17:22, Armen wrote:
> I am using swupdate 2019.11 to do software updates for our embedded
> system. We have implemented version check feature where swupdate will
> only update components that have mismatch in versions reported by the
> hardware (in /etc/sw-versions) and in the new .swu package.

Ok

>
> However, it seems like swupdate only reads this sw-versions file into
> memory during start up process of swupdate server (swupdate.service) -
> using method: read_sw_version_file.

It is.

>
> While our system is online, we may perform manual updates (not using
> swupdate) or hot-swap compoments. This will result in versions running
> on the hardware being different from what is stored in sw-versions
> copied from last swupdate upgrade.

Well, SWupdate does not know that you updated some components.

>
> To resolve this problem, we perform update of sw-versions file before
> each new swupdate call (using swupdate-client). This way we populate
> sw-versions with real-time versions information on the HW. However, when
> we run swupdate-client, the updated sw-versions file is never checked.

This is not supported.

> swupdate is using value that were previously loaded into memory at boot
> up of the hardware.

Correct.

>
> How do I fix this problem? Is there something in swupdate that can
> trigger execution of read_sw_version_file method?

Not yet.

I think this could be implemented as IPC command, and new version of a
component is sent to SWUpdate.

> Besides forcing
> swupdate.service to restart, is there anything I can do in pre-install
> scripts I do not want to restart system.
>

Best regards,
Stefano Babic