hawkBit reinstalls same deployment after reboot

[ayoub...@googlemail.com]

Hi,

swupdate 2026.05 after a deployment is installed and the device reboots, swupdate downloads and installs the same deployment a second time before the application has a chance to confirm success or failure.

Trace:

[do_get_state]   : Read state=1 from persistent storage.
POST .../deploymentBase/126/feedback:
   { "finished":"none","execution":"proceeding",
     "details":["Update Installed, Testing Pending."] }
< HTTP/1.1 200 OK
[do_get_state]   : Read state=0 from persistent storage. 
[start_suricatta]: About to process available update.
... full install runs a second time ...

The root cause I believe is that server_handle_initial_state() unconditionally calls save_state(STATE_OK) right after posting "Testing Pending". 

The guard in server_has_pending_action() at https://github.com/sbabic/swupdate/blob/master/suricatta/server_hawkbit.c#L806 

is designed to prevent re-processing while (get_state() == STATE_INSTALLED) but it can never fire because the state has just been cleared.

is my reading is correct ?

Thanks,
Ayoub

[Stefano Babic]

Hi Ayoub,

Have you passed the status of the update when SWUpdate is started ? That
is with -u "-c 2" or -u "-c 6" ?

If SWUpdate knows which is the status after reboot (ok, or failed, that
means a fallback took place), it sends the feedback to Hawkbit and the
server closes the transaction. If not, it is handled as normal boot
without update, Hawkbit still presents the SWU, and SWUpdate will start
again.

Best regards,
Stefano

--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

[ayoub...@googlemail.com]

Hi Stefano,

I'm trying to avoid that and have swupdate-ipc sendtohawkbit sending the confirmation to the Hawkbit server 

after validating the now booting slot ( no watchdog triggered/ health-check okay) this of course is delayed and happening only after swupdate is started.

Is this scenario considered at all ? what's the point then of sendtohawkbit ?

If SWUpdate knows which is the status after reboot (ok, or failed, that
means a fallback took place), it sends the feedback to Hawkbit and the
server closes the transaction. If not, it is handled as normal boot
without update, Hawkbit still presents the SWU, and SWUpdate will start
again.

Best,

Ayoub 

[Stefano Babic]

Hi Ayoub,

> sbabic/ <https://github.com/sbabic/>

> > swupdate/blob/master/suricatta/server_hawkbit.c#L806
> > is designed to prevent re-processing while (get_state() ==
> > STATE_INSTALLED) but it can never fire because the state has just
> been
> > cleared.
> >
> > is my reading is correct ?
> >
>
> Have you passed the status of the update when SWUpdate is started ?
> That
> is with -u "-c 2" or -u "-c 6" ?
>
>
> I'm trying to avoid that and have swupdate-ipc sendtohawkbit sending the
> confirmation to the Hawkbit server

swupdate-ipc is not necessary.

The use case with swupdate-ipc is when the confirmation should be sent
later by the application, or there is a HMI and the operator / end
customer must acknowledge the new version.

> after validating the now booting slot ( no watchdog triggered/ health-
> check okay) this of course is delayed and happening only after swupdate
> is started.

See my last email - the use case is that software is running, and the
glue logic to start SWUpdate sets the parameters to inform about the
result, that is via -u "--confirm 2" (Ok), -u "--confirm 3" (FAILED) or
-u "--confirm 6" (WAIT).

>
> Is this scenario considered at all ? what's the point then of
> sendtohawkbit ?

sendtohawkbit is for the use cases where an external tool / application
/ whatever decides if the update is ok or not. As your use case if that
system is up again, you have to inject the right parameter when SWUpdate
is started.

[ayoub...@googlemail.com]

Hi Stefano,

this is exactly my use case: dont' want swupdate to confirm because it start the systemd unit ealry and has no knowldege 

if the overall system is healthy yet and need to be confirmed later by another application.

> after validating the now booting slot ( no watchdog triggered/ health-
> check okay) this of course is delayed and happening only after swupdate
> is started.

See my last email - the use case is that software is running, and the
glue logic to start SWUpdate sets the parameters to inform about the
result, that is via -u "--confirm 2" (Ok), -u "--confirm 3" (FAILED) or
-u "--confirm 6" (WAIT).

then the right one seems to be then:  --confirm 6  :-)

Couldn't swupdate handle it automatically in that case ? it can read ustate and action_id from uboot env ?

>
> Is this scenario considered at all ? what's the point then of
> sendtohawkbit ?

sendtohawkbit is for the use cases where an external tool / application
/ whatever decides if the update is ok or not. As your use case if that
system is up again, you have to inject the right parameter when SWUpdate
is started. 

thanks for the clarifications.

best,

Ayoub 

[ayoub...@googlemail.com]

could this patch be considered :

https://raw.githubusercontent.com/embetrix/meta-raspberrypi-secure/32e6e52042c00baa2698cd17130607f07719a25c/recipes-support/swupdate/files/0006-suricatta-hawkbit-don-t-reset-ustate-INSTALLED-befor.patch

[Stefano Babic]

Hi Ayoub,

> > sbabic/ <https://github.com/sbabic/ <https://github.com/sbabic/>>

> > > swupdate/blob/master/suricatta/server_hawkbit.c#L806
> > > is designed to prevent re-processing while (get_state() ==
> > > STATE_INSTALLED) but it can never fire because the state has just
> > been
> > > cleared.
> > >
> > > is my reading is correct ?
> > >
> >
> > Have you passed the status of the update when SWUpdate is started ?
> > That
> > is with -u "-c 2" or -u "-c 6" ?
> >
> >
> > I'm trying to avoid that and have swupdate-ipc sendtohawkbit
> sending the
> > confirmation to the Hawkbit server
>
> swupdate-ipc is not necessary.
>
> The use case with swupdate-ipc is when the confirmation should be sent
> later by the application, or there is a HMI and the operator / end
> customer must acknowledge the new version.
>
>
> this is exactly my use case: dont' want swupdate to confirm because it
> start the systemd unit ealry and has no knowldege
> if the overall system is healthy yet and need to be confirmed later by
> another application.

Then you have to start SWUpdate in WAIT state and your application
should send via IPC the acknowledgement with the result.

>
>
>
> > after validating the now booting slot ( no watchdog triggered/
> health-
> > check okay) this of course is delayed and happening only after
> swupdate
> > is started.
>
> See my last email - the use case is that software is running, and the
> glue logic to start SWUpdate sets the parameters to inform about the
> result, that is via -u "--confirm 2" (Ok), -u "--confirm 3" (FAILED) or
> -u "--confirm 6" (WAIT).
>
>
> then the right one seems to be then:  --confirm 6  :-)
>

Right.

> Couldn't swupdate handle it automatically in that case ? it can read
> ustate and action_id from uboot env ?

ustate is then not needed anymore, you have already evaluated and passed
the WAIT state.

Action-id is extracted automatically by SWUpdate by using a namespace
from the environment, that is a parallel environment not touched by the
bootloader.

>
> >
> > Is this scenario considered at all ? what's the point then of
> > sendtohawkbit ?
>
> sendtohawkbit is for the use cases where an external tool / application
> / whatever decides if the update is ok or not. As your use case if that
> system is up again, you have to inject the right parameter when
> SWUpdate
> is started.
>
>
> thanks for the clarifications.
>

[Stefano Babic]

Hi Ayoub,

On 6/23/26 18:00, 'ayoub...@googlemail.com' via swupdate wrote:
> could this patch be considered :
>
> https://raw.githubusercontent.com/embetrix/meta-raspberrypi-
> secure/32e6e52042c00baa2698cd17130607f07719a25c/recipes-support/
> swupdate/files/0006-suricatta-hawkbit-don-t-reset-ustate-INSTALLED-
> befor.patch
>

No, the use case is already supported, in a different way as you have
thought. The evaluation of ustate finished when SWUpdate is started.

Your use case requires to put SWUpdate in the WAIT case, then it behaves
exactly as you want.

Best regards,
Stefano

> github.com/ <https://github.com/>
> > sbabic/ <https://github.com/sbabic/ <https://github.com/

> --
> 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/561b928b-4989-493d-889e-6687cfb3c744n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> swupdate/561b928b-4989-493d-889e-6687cfb3c744n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.