Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

IN_SYNC and rollout success can be recorded while the device still runs the old image

Open
  • Is something wrong?
#3,185 0 comments 1 reaction 1 assignee View on GitHub

Maintainers usually reply within 1 day

@denislavprinov is already working on this.

Since Jul 6, 2026.

Assessment

This issue has not been assessed yet.

Description

Hi!

We reproduced the behavior below against a real hawkBit server, with the RAUC hawkBit Updater acting as the device client.
Because the updater side is already tracked upstream in rauc/rauc-hawkbit-updater#161 and rauc/rauc#1114, we are flagging the server and rollout side here.

There are two parts to it.

  1. In hawkBit, each managed device is a target, which reports progress through an agent that hawkBit calls controller. When that controller posts finished=success the moment the install is written to disk, before any reboot and before the device confirms a good boot, hawkBit marks the target IN_SYNC and treats it as carrying its assigned software (its distribution set). If the target sits in a rollout configured with successAction=NEXTGROUP, the rollout engine counts that group as done and advances to the next group on its own. A rollout can therefore finish without any target having booted the new software at all.
  2. Many embedded devices use an A/B layout (meaning two system slots where a failed update can fall back to the slot that still works). Suppose a device reboots into the new slot but fails there and falls back to the previous one. hawkBit leaves both the IN_SYNC state and its record of the installed version (installedBase) untouched. Its own view then still shows the target as updated while the device runs the earlier image. This is I think the same as #446 opened super long ago. #242, for a device to report the version it is running, is also related.

Actually, hawkBit is somehow behaving as designed here. It records the feedback that a controller reports and does not independently check whether the new image has booted, which is a fair line for a management server to draw. The caution is for any system that reads a target's status from hawkBit. IN_SYNC and rollout success both describe an install that a device reported. Neither one confirms that the new image is the one currently running. A security or safety decision should not rest on them as proof that the device booted the update.

So the question is: is there any plan to expose a separate confirmed-running state? It could come from a device reporting the version it is running (along the lines of #242), or from a post-boot confirmation that has to arrive before hawkBit records final success. Either form would let downstream systems that gate on target status stop reading an install report as proof of a running image.

Thanks!
Flavien

Dominant language
Java
Stars
601
Forks
228
Avg merge
15h 58m
Merged PRs (30d)
62

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from eclipse-hawkbit/hawkbit

All issues in eclipse-hawkbit/hawkbit

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.