Unexpected behavior on installed_sw_list element update

[Clément Ramirez (DiyVE)]

Hi,

I'm currently using the gen-swversions feature to automatically updating the sw-versions file upon successful update.

While testing the feature, I saw the sw-versions file may be updated with incorrectly installed artifacts depending on subsequent installs made on the product.
Let me explain myself with the following example :

I want to install swu A which contains one file artifact and one postinstall script artifact.
Both artifacts are containing version and name entry to allow them to be written to the sw-versions, in case of successful update.

During install the file (not using installed-directly parameter) is correctly deployed on the device, but the script failed to execute correctly.

In this case update status is considered FAILED, and the sw-versions is not updated, which is what we wanted.

However, I now want to install swu B, which also contains 2 artifacts with name and version parameters.
The update were successful and the sw-versions has to be updated only with the artifacts corresponding to this swu.
But, when looking at the sw-versions file, I observed the file is tainted with artifacts from swu A, which is not something expected I think (by looking at the thread [0]).

While analysing the install_images function from the installer.c file I saw the installed_sw_list list is updated each time an artifact is correctly installed (even if the gen-swversion is disabled).
And this list will be kept as long as swupdate is running, which can also cause issues when trying to install subsequent updates without rebooting the swupdate process.

A possible fix I can start implement is :

We can only update the installed_sw_list element when the update is successful and when the gen-swversions feature is enabled.

[0] : https://groups.google.com/g/swupdate/c/uXdoBDB5cpQ/m/Ew_5GqsXCAAJ

Have a nice day,

Sincerely,
Clément Ramirez

[Stefano Babic]

Hi Clement,

SWUpdate tracks each step, this is correct.

> And this list will be kept as long as swupdate is running, which can
> also cause issues when trying to install subsequent updates without
> rebooting the swupdate process.

This is not the cause.

>
> A possible fix I can start implement is :
> We can only update the installed_sw_list element when the update is
> successful and when the gen-swversions feature is enabled.
>
> [0] : https://groups.google.com/g/swupdate/c/uXdoBDB5cpQ/m/Ew_5GqsXCAAJ
>

No.

SWUpdate maintains and updates each internal structures for the time of
an update. At the end of each transaction (failed or successful), this
structures are freed.

The structures related to the versions (installed_sw_list ) are not
freed after an update. This is done in cleanup_files(), where temporary
lists are iterated and each element is freed. The right solution (I
confirm from code that this bug exists) is to release the allocated list
inside the cleanup function.

Best regards,
Stefano Babic

> Have a nice day,
>
> Sincerely,
> Clément Ramirez
>

> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/9e7aa688-2460-4012-ac08-d4fb58630fc6n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/9e7aa688-2460-4012-ac08-
> d4fb58630fc6n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Clément Ramirez]

Hi Stefano,

Thanks for you answer,

> SWUpdate maintains and updates each internal structures for the time of
> an update. At the end of each transaction (failed or successful), this
> structures are freed.
>
> The structures related to the versions (installed_sw_list ) are not
> freed after an update. This is done in cleanup_files(), where temporary
> lists are iterated and each element is freed. The right solution (I
> confirm from code that this bug exists) is to release the allocated list
> inside the cleanup function.

So If I understand correctly a solution could be to free the entire
installed_sw_list
structure and then maybe re-create it from the sw-versions file (for
what I see from code this
is done once during startup).
Or maybe do this operation in 2 steps. First free the structure in the
cleanup_files()
function as you mentioned it and then re-read the sw-versions contents when a
new update will be started over.
In this case reading the sw-versions file can be done in the network_thread()
function (under the REQ_INSTALL case).

If we don't re-read the list, any artifacts might be installed
regardless of their installation
status, registered within sw-versions file.

Have a nice day,
Clément Ramirez

[Stefano Babic]

Hi Clement,

On 10/9/25 11:50, Clément Ramirez wrote:
> Hi Stefano,
>
> Thanks for you answer,
>
>> SWUpdate maintains and updates each internal structures for the time of
>> an update. At the end of each transaction (failed or successful), this
>> structures are freed.
>>
>> The structures related to the versions (installed_sw_list ) are not
>> freed after an update. This is done in cleanup_files(), where temporary
>> lists are iterated and each element is freed. The right solution (I
>> confirm from code that this bug exists) is to release the allocated list
>> inside the cleanup function.
>
> So If I understand correctly a solution could be to free the entire
> installed_sw_list
> structure and then maybe re-create it from the sw-versions file (for
> what I see from code this
> is done once during startup).
> Or maybe do this operation in 2 steps. First free the structure in the
> cleanup_files()
> function as you mentioned it and then re-read the sw-versions contents when a
> new update will be started over.

The issue was created by adding the feature because it was not split
between configuration (read from /etc/sw-versions or /etc/swupdate.cfg)
and runtime. Runtime is overwriting the configuration and this leads to
the problem.

IMHO it should be better solved in another way. Rereading the file is
dummy, SWUpdate has already the list. So the whole list shouldn't be
erased, just the runtime part (that doesn't currently exist).

So the struct sw_version should be extended, and it should have twice
name/version pair, one for the configuration (that does not change) and
one for the runtime (added after each successful installation of an
artifact), and in cleanup the runtime values are erased without changing
the configuration values.

> In this case reading the sw-versions file can be done in the network_thread()
> function (under the REQ_INSTALL case).
>
> If we don't re-read the list, any artifacts might be installed
> regardless of their installation
> status, registered within sw-versions file.
>

Best regards,
Stefano Babic

[Clément Ramirez]

Hi again Stefano,

> > So If I understand correctly a solution could be to free the entire
> > installed_sw_list
> > structure and then maybe re-create it from the sw-versions file (for
> > what I see from code this
> > is done once during startup).
> > Or maybe do this operation in 2 steps. First free the structure in the
> > cleanup_files()
> > function as you mentioned it and then re-read the sw-versions contents when a
> > new update will be started over.
>
> The issue was created by adding the feature because it was not split
> between configuration (read from /etc/sw-versions or /etc/swupdate.cfg)
> and runtime. Runtime is overwriting the configuration and this leads to
> the problem.
>
> IMHO it should be better solved in another way. Rereading the file is
> dummy, SWUpdate has already the list. So the whole list shouldn't be
> erased, just the runtime part (that doesn't currently exist).

Yes I agree with you, since we already have the information, better
reusing it again.

> So the struct sw_version should be extended, and it should have twice
> name/version pair, one for the configuration (that does not change) and
> one for the runtime (added after each successful installation of an
> artifact), and in cleanup the runtime values are erased without changing
> the configuration values.
>

That makes sense. However, what should we do if we need to update the
configuration structure due to a successful update with the gen-swversions
feature enabled?
In such a case, the sw-versions file is updated with the newly
installed artifacts.
In my view, it would be appropriate for subsequent installations to
take this modification
into account, and thus, update the configuration structure.

Sincerely,
Clément Ramirez

[Stefano Babic]

Hi Clement,

This requires a reboot to take place.

> In such a case, the sw-versions file is updated with the newly
> installed artifacts.
> In my view, it would be appropriate for subsequent installations to
> take this modification
> into account, and thus, update the configuration structure.
>

We do not know - it could be that update is successful, but activation
is done by an external agent and it decides to not restart. The still
activated artifacts are the only one, and a new update should still
overwrite them.

In case reboot is not required, SWUpdate cannot decide at all. There
will be cases where new artifacts replace the old one without
restarting, and then it makes sense what you are proposing, but also
cases where the new artifacts are just installed. If this becomes a new
feature, SWUpdate should be informed (via some new attribute in
sw-description) what should be done, for example to update the
configuration structure at the end of the update.

Best regards,
Stefano

> Sincerely,
> Clément Ramirez

[Clément Ramirez]

Hi Stefano,

> We do not know - it could be that update is successful, but activation
> is done by an external agent and it decides to not restart. The still
> activated artifacts are the only one, and a new update should still
> overwrite them.
>
> In case reboot is not required, SWUpdate cannot decide at all. There
> will be cases where new artifacts replace the old one without
> restarting, and then it makes sense what you are proposing, but also
> cases where the new artifacts are just installed. If this becomes a new
> feature, SWUpdate should be informed (via some new attribute in
> sw-description) what should be done, for example to update the
> configuration structure at the end of the update.

Yes this can be a great swupdate feature to add.
I was however thinking the gen-swersions parameter
could be used to determine if the user wants to consider the
artifacts activated upon successful install (because the new artifacts
will be written to sw-versions). As this parameters is placed into swupdate.cfg,
this is static at runtime and is hence applied for all the
sw-description parsed.

Anyway, I started working on the fix you proposed with the duplicated versions :
struct sw_version {
char name[SWUPDATE_GENERAL_STRING_SIZE];
char config_version[SWUPDATE_GENERAL_STRING_SIZE];
char runtime_version[SWUPDATE_GENERAL_STRING_SIZE];
bool install_if_different;
bool install_if_higher;
LIST_ENTRY(sw_version) next;
};

Do you want me to submit the patch in this thread or a new one ?

Have a good day,

Clément RAMIREZ

[Stefano Babic]

Hi Clement,

On 10/11/25 08:35, Clément Ramirez wrote:
> Hi Stefano,
>
>> We do not know - it could be that update is successful, but activation
>> is done by an external agent and it decides to not restart. The still
>> activated artifacts are the only one, and a new update should still
>> overwrite them.
>>
>> In case reboot is not required, SWUpdate cannot decide at all. There
>> will be cases where new artifacts replace the old one without
>> restarting, and then it makes sense what you are proposing, but also
>> cases where the new artifacts are just installed. If this becomes a new
>> feature, SWUpdate should be informed (via some new attribute in
>> sw-description) what should be done, for example to update the
>> configuration structure at the end of the update.
>
> Yes this can be a great swupdate feature to add.
> I was however thinking the gen-swersions parameter
> could be used to determine if the user wants to consider the
> artifacts activated upon successful install (because the new artifacts
> will be written to sw-versions). As this parameters is placed into swupdate.cfg,
> this is static at runtime and is hence applied for all the
> sw-description parsed.

It depends how you have integrated SWUpdate in the project. swupdate.cfg
can be just a template and runtime attributes are set during the boot to
pass the correct file to SWUpdate.

>
> Anyway, I started working on the fix you proposed with the duplicated versions :
> struct sw_version {
> char name[SWUPDATE_GENERAL_STRING_SIZE];
> char config_version[SWUPDATE_GENERAL_STRING_SIZE];
> char runtime_version[SWUPDATE_GENERAL_STRING_SIZE];
> bool install_if_different;
> bool install_if_higher;
> LIST_ENTRY(sw_version) next;
> };
>
> Do you want me to submit the patch in this thread or a new one ?
>

A patch is always in a separate thread because it must be collected by
patchwork. See the contributing page in the documentation.

Best regards,
Stefano Babic