2023.12-r0 - How to notify the OTA success later ?
23 views
Skip to first unread message
Kakao Yong
Nov 13, 2025, 4:20:27 AMNov 13
to swupdate
Hello,
We are using 2023.12-r0 version of swupdate in a Yocto system.
We would like to implement a mechanism where, when an OTA is available, it is downloaded and installed (in the sense of being flashed), but at this stage, we don't want any confirmation message sent to the Hawkbit server.
However, our application then notifies the user, and the user decides when to reboot.
Then, upon reboot, we want our application to tell swupdate that it can send the confirmation message indicating "OTA successful."
How can we do this?
It seems to me that no matter what we do, swupdate sends a confirmation to the Hawkbit server indicating "OTA successful" once the OTA is installed (in the sense of being flashed).
However, our application then notifies the user, and the user decides when to reboot.
Then, upon reboot, we want our application to tell swupdate that it can send the confirmation message indicating "OTA successful."
How can we do this?
It seems to me that no matter what we do, swupdate sends a confirmation to the Hawkbit server indicating "OTA successful" once the OTA is installed (in the sense of being flashed).
Stefano Babic
Nov 13, 2025, 4:28:13 AMNov 13
to Kakao Yong, swupdate
Hi Kakao,
On 11/13/25 10:18, Kakao Yong wrote:
> Hello,
>
> We are using 2023.12-r0 version of swupdate in a Yocto system.
>
> We would like to implement a mechanism where, when an OTA is available,
> it is downloaded and installed (in the sense of being flashed), but at
> this stage, we don't want any confirmation message sent to the Hawkbit
> server.
Ok, it is a use case.
>
> However, our application then notifies the user, and the user decides
> when to reboot.
No problem.
>
> Then, upon reboot, we want our application to tell swupdate that it can
> send the confirmation message indicating "OTA successful."
>
> How can we do this?
I do not see problems - SWUpdate does not send any notification until it
is not explicitely stated. The only case when SWUpdate sends a
notification after installing is if reboot is set to false in
sw-description.
Else after a reboot you start SWUpdate with the -u "-c <code>", anjd
SWUpdate sends success or failure to Hawkbit.
>
> It seems to me that no matter what we do, swupdate sends a confirmation
> to the Hawkbit server indicating "OTA successful"
It does not, there is no code for this, SWUpdate sends a notification
only when restarted, that means after a reboot.
> once the OTA is
> installed (in the sense of being flashed).
No, it is not.
Best regards,
Stefano Babic
On 11/13/25 10:18, Kakao Yong wrote:
> Hello,
>
> We are using 2023.12-r0 version of swupdate in a Yocto system.
>
> We would like to implement a mechanism where, when an OTA is available,
> it is downloaded and installed (in the sense of being flashed), but at
> this stage, we don't want any confirmation message sent to the Hawkbit
> server.
>
> However, our application then notifies the user, and the user decides
> when to reboot.
>
> Then, upon reboot, we want our application to tell swupdate that it can
> send the confirmation message indicating "OTA successful."
>
> How can we do this?
is not explicitely stated. The only case when SWUpdate sends a
notification after installing is if reboot is set to false in
sw-description.
Else after a reboot you start SWUpdate with the -u "-c <code>", anjd
SWUpdate sends success or failure to Hawkbit.
>
> It seems to me that no matter what we do, swupdate sends a confirmation
> to the Hawkbit server indicating "OTA successful"
only when restarted, that means after a reboot.
> once the OTA is
> installed (in the sense of being flashed).
Best regards,
Stefano Babic
Kakao Yong
Nov 13, 2025, 5:13:08 AMNov 13
to swupdate
Hello,
Yes I see about the "reboot" feature.
But the problem is: When I enable the reboot feature, it reboots immediately when the OTA is flashed!
We would like to "have the control on the reboot"
I see two options but I don't really like them:
1. Use reboot = false (like now) so that we can control the reboot by our application (not swupdate). But it implies:
- To patch the code to not transmit the conclusion to hawkbit
- or to stop (kill) swupdate in our installation script
2. Use reboot = true (like you suggest), but patch the code that is really acting the reboot to prevent this code from rebooting the system.
Is there another best solution ?
I am thinking on another option:
Use reboot = 1 and after OTA success, put an infinite loop with sleep commands, to make sure it nevers gives the hands to swupdate, so it doesn't trig the reboot
Also this is not important, but note that with my version of swupdate, the "reboot" flag is not correctly read according to documentation. The documentation say's:
Attribute belongs to the general section, where also version belongs. It is
not required to activate the flag with `reboot = true` because it is the
default behavior, so just disabling makes sense.
not required to activate the flag with `reboot = true` because it is the
default behavior, so just disabling makes sense.
But if we put reboot = true; in sw-description, it is not read as 1 (RUN [get_common_fields] : rebot_required 0), but reboot = 1; is correctly read as 1: (RUN [get_common_fields] : rebot_required 1)
Best regards,
Stefano Babic
Nov 13, 2025, 5:58:44 AMNov 13
to Kakao Yong, swupdate
Hello,
On 11/13/25 11:13, Kakao Yong wrote:
> Hello,
>
> Yes I see about the "reboot" feature.
>
> But the problem is: When I enable the reboot feature, it reboots
> immediately when the OTA is flashed!
>
Because you have probably the swupdate-progrtess service that is started
with "-r" parameter (reboot). Remove it, and system does not reboot.
SWUpdate itself (core) does not reboot at all if you do not add
explicitly a postinstall command asking for rebooting.
> We would like to "have the control on the reboot"
>
> I see two options but I don't really like them:
> 1. Use reboot = false (like now) so that we can control the reboot by
> our application (not swupdate). But it implies:
No, it is not in this way. reboot = false is used for packages (maybe
just the application) that do not require a reboot. And it is used to
inform external software that a reboot for this update is not required.
Control of reboot is already demanded outside SWUpdate.
> - To patch the code to not transmit the conclusion to hawkbit
There is no code to transmit it after an update, this happens only after
a reboot or via IPC (that you surely not have implemented), so you plan
to patch nothing.
> - or to stop (kill) swupdate in our installation script
...well, I avoid to say anything...
> 2. Use reboot = true (like you suggest), but patch the code that is
> really acting the reboot to prevent this code from rebooting the system.
No, you are not getting the point.
SWupdate does not reboot itself, it communicates that an update is
successful. This allows to implement own logic, as in your case, and in
many other cases.
A default tool for this is swupdate-progress, that in your integration
is probably started with -r parameter. If you change this, system does
not reboot.
Or you have forced SWUpdate to reboot in an nother way, but then your
integration is buggy and you have to solve this.
>
> Is there another best solution ?
>
> I am thinking on another option:
>
> *Use reboot = 1 and after OTA success, put an infinite loop with sleep
>
Do you think this is a good option ? Really ?
>
> Also this is not important, but note that with my version of swupdate,
> the "reboot" flag is not correctly read according to documentation. The
> documentation say's:> > Attribute belongs to the general section, where also version belongs.
It is
> not required to activate the flag with `reboot = true` because it is the
> default behavior, so just disabling makes sense.
>
> But if we put reboot = true; in sw-description, it is not read as 1 (RUN
> [get_common_fields] : rebot_required 0), but reboot = 1; is correctly
> read as 1: (RUN [get_common_fields] : rebot_required 1)
>
Documentation is saying that just "false" makes sense.....
Best regards,
Stefano Babic
> --
> 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/85fd2720-140f-47b3-bb74-162bc70a099fn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/85fd2720-140f-47b3-
> bb74-162bc70a099fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
On 11/13/25 11:13, Kakao Yong wrote:
> Hello,
>
> Yes I see about the "reboot" feature.
>
> But the problem is: When I enable the reboot feature, it reboots
> immediately when the OTA is flashed!
>
with "-r" parameter (reboot). Remove it, and system does not reboot.
SWUpdate itself (core) does not reboot at all if you do not add
explicitly a postinstall command asking for rebooting.
> We would like to "have the control on the reboot"
>
> I see two options but I don't really like them:
> 1. Use reboot = false (like now) so that we can control the reboot by
> our application (not swupdate). But it implies:
just the application) that do not require a reboot. And it is used to
inform external software that a reboot for this update is not required.
Control of reboot is already demanded outside SWUpdate.
> - To patch the code to not transmit the conclusion to hawkbit
a reboot or via IPC (that you surely not have implemented), so you plan
to patch nothing.
> - or to stop (kill) swupdate in our installation script
> 2. Use reboot = true (like you suggest), but patch the code that is
> really acting the reboot to prevent this code from rebooting the system.
SWupdate does not reboot itself, it communicates that an update is
successful. This allows to implement own logic, as in your case, and in
many other cases.
A default tool for this is swupdate-progress, that in your integration
is probably started with -r parameter. If you change this, system does
not reboot.
Or you have forced SWUpdate to reboot in an nother way, but then your
integration is buggy and you have to solve this.
>
> Is there another best solution ?
>
> I am thinking on another option:
>
> commands, to make sure it nevers gives the hands to swupdate, so it
> doesn't trig the reboot*
>
Do you think this is a good option ? Really ?
>
> Also this is not important, but note that with my version of swupdate,
> the "reboot" flag is not correctly read according to documentation. The
> documentation say's:> > Attribute belongs to the general section, where also version belongs.
It is
> not required to activate the flag with `reboot = true` because it is the
> default behavior, so just disabling makes sense.
>
> But if we put reboot = true; in sw-description, it is not read as 1 (RUN
> [get_common_fields] : rebot_required 0), but reboot = 1; is correctly
> read as 1: (RUN [get_common_fields] : rebot_required 1)
>
Best regards,
Stefano Babic
> 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/85fd2720-140f-47b3-bb74-162bc70a099fn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/85fd2720-140f-47b3-
> bb74-162bc70a099fn%40googlegroups.com?utm_medium=email&utm_source=footer>.
Reply all
Reply to author
Forward
0 new messages