Hawkbit soft/forced updates and swupdate IPC post-update processing

[Cal]

Group,

It appears that the IPC from swupdate to swupdate-progress does not forward the "soft" vs "forced" update information that Hawkbit configures for a rollout. Or, if it does, swupdate-progress is not forwarding the information to the `-e` script. That script just receives the SUCCESS or FAILURE message.

I double-checked the swupdate post-update command as well, just to be sure there wasn't another avenue for taking advantage of the soft/forced feature, and I see that no parameters are passed to it that post-update command.

I don't see a way to take advantage of the feature by using scripts or configuration in swupdate, so I'm thinking the next best step would be creating a patch that supports that behavior.

Before I dive into creating a patch, is anyone aware of other work being done on this functionality? Or is anyone aware of alternate solutions to achieve the same result? The only other alternative I've found is putting lua scripts or uboot env variable changes in the .swu to set flags that can be parsed by post-update scripts, but that alternative seems like a workaround for a missing feature.

Thanks,

Caleb

[Stefano Babic]

Hi Cal,

On 9/27/25 00:04, 'Cal' via swupdate wrote:
> Group,
>
> It appears that the IPC from swupdate to swupdate-progress does not
> forward the "soft" vs "forced" update information that Hawkbit
> configures for a rollout.

update information is forwarded from SWUpdate (suricatta system, Hawkbit
server) to all listeners of the progress interface. This is done here:

https://github.com/sbabic/swupdate/blob/master/suricatta/server_hawkbit.c#L252

> Or, if it does, swupdate-progress is not
> forwarding the information to the `-e` script.

This is possible, yes. Not all information are managed by swupdate-progress.

> That script just receives
> the SUCCESS or FAILURE message.
>

Correct - this is the only information received by the script.

> I double-checked the swupdate post-update command as well, just to be
> sure there wasn't another avenue for taking advantage of the soft/forced
> feature, and I see that no parameters are passed to it that post-update
> command.

They are not passed.

>
> I don't see a way to take advantage of the feature by using scripts or
> configuration in swupdate, so I'm thinking the next best step would be
> creating a patch that supports that behavior.
>
> Before I dive into creating a patch, is anyone aware of other work being
> done on this functionality?

At the early beginning, swupdate-progress was thought as example for the
progress API. Most usage was just to reboot the system outside SWUpdate.

The meaning of the progress interface is to give as many details
possible regarding tthe update, and let an external control logic to
take the decisions. So it is a way to bind own code and to get informed
about the update.

With the time, swupdate-progress is reused as it is in many projects,
becoming more a ready to use tool than just an example. Script
functionality was added later. But also some information from SWUpdate's
core via the progress interface are just discarded.

> Or is anyone aware of alternate solutions to
> achieve the same result? The only other alternative I've found is
> putting lua scripts or uboot env variable changes in the .swu to set
> flags that can be parsed by post-update scripts, but that alternative
> seems like a workaround for a missing feature.

It is not thought in this way, this is just a hack.

The way to have full blown control was to use the API and write own
code. Then own logic control has all information and can be customized
according to the project.

If swupdate-progress should be able to take care of these information
(like forced / soft). it must be extended. Think about that the tool
runs in any condition, not only if update is done via Hawkbit.

Best regards,
Stefano Babic

>
> Thanks,
> Caleb
>
> --
> 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/8e828851-5c80-426e-bc30-a2a7e01ccf91n%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/8e828851-5c80-426e-bc30-
> a2a7e01ccf91n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Storm, Christian]

Hi,

>> It appears that the IPC from swupdate to swupdate-progress does not forward the "soft" vs "forced" update information that Hawkbit configures for a rollout.
>
> update information is forwarded from SWUpdate (suricatta system, Hawkbit server) to all listeners of the progress interface. This is done here:
>
> https://github.com/sbabic/swupdate/blob/master/suricatta/server_hawkbit.c#L252
>
>> Or, if it does, swupdate-progress is not forwarding the information to the `-e` script.
>
> This is possible, yes. Not all information are managed by swupdate-progress.
>
>> That script just receives the SUCCESS or FAILURE message.
>
> Correct - this is the only information received by the script.
>
>> I double-checked the swupdate post-update command as well, just to be sure there wasn't another avenue for taking advantage of the soft/forced feature, and I see that no parameters are passed to it that post-update command.
>
> They are not passed.
>
>> I don't see a way to take advantage of the feature by using scripts or configuration in swupdate, so I'm thinking the next best step would be creating a patch that supports that behavior.
>> Before I dive into creating a patch, is anyone aware of other work being done on this functionality?
>
> At the early beginning, swupdate-progress was thought as example for the progress API. Most usage was just to reboot the system outside SWUpdate.
>
> The meaning of the progress interface is to give as many details possible regarding tthe update, and let an external control logic to take the decisions. So it is a way to bind own code and to get informed about the update.
>
> With the time, swupdate-progress is reused as it is in many projects, becoming more a ready to use tool than just an example. Script functionality was added later. But also some information from SWUpdate's core via the progress interface are just discarded.
>
>> Or is anyone aware of alternate solutions to achieve the same result? The only other alternative I've found is putting lua scripts or uboot env variable changes in the .swu to set flags that can be parsed by post-update scripts, but that alternative seems like a workaround for a missing feature.
>
> It is not thought in this way, this is just a hack.
>
> The way to have full blown control was to use the API and write own code. Then own logic control has all information and can be customized according to the project.
>
> If swupdate-progress should be able to take care of these information (like forced / soft). it must be extended. Think about that the tool runs in any condition, not only if update is done via Hawkbit.

Just as an example how to extend the (once example) progress client, see this thread
https://groups.google.com/g/swupdate/c/qYcSPLLkeD4/m/SfWZ7OGnBAAJ
passing the dry-run property to the progress client in order to inhibit rebooting in certain conditions.
Granted, this is information actually needed by the progress client to react properly on non-reboot activated artifacts.
Nonetheless, along this way, more information could be passed. The question is why and what information is passed?


Kind regards,
Christian

--
Dr. Christian Storm
Siemens AG, FT RPD CED
Friedrich-Ludwig-Bauer-Str. 3, 85748 Garching, Germany