You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In a typical implementation of RAUC it is the responsibility of the newly updated slots to mark their status good or bad.
rauc-hawkbit-updater to my knowledge does not support reporting success back to hawkbit after the newly updated slot has been validated via a boot or external test, rather it reports success immediately upon a ""successful"" install.
I would consider this a problem as it may falsely label a failed install as successful. This is made worse by Hawkbit's lack of API to update the recorded software version number. So not only is a failed install labeled as successful, Hawkbits is unaware of any rollback the target system has performed and will skip reinstall attempts because it thinks the current software is up to date.
See this other user with similar problems: eclipse-hawkbit/hawkbit#446
With SWUpdate's Hawkbit client, it's the responsibility of the updated OS to report a successful install... I think... or its reporting mechanism is broken.
Am I the only person seeing this problem or am missing something in my implementation?
Is it possible to have rauc-hawkbit-updater only inform hawkbit of a successful update after the update has been truly validated?
The text was updated successfully, but these errors were encountered:
Am I the only person seeing this problem or am missing something in my implementation?
No, you aren't. I am fully aware that the current approach actually reports the successful installation too early.
Is it possible to have rauc-hawkbit-updater only inform hawkbit of a successful update after the update has been truly validated?
In principle, this is possible, yes. But to realize this with RAUC in a robust manner, there is a number of puzzle pieces missing.
Parts of what is missing I have documented in the RAUC concept issue rauc/rauc#1114.
The short version is that from RAUC's perspective, we have no existing way yet to mark or detect a specific installation as successful after reboot. The overall concept that would allow such things we referred to as "life-cycle handling".
With the latest v1.10 release of RAUC, an important puzzle piece for your use case already made its way into RAUC: A transaction UUID that allows us to unambiguously identify an installation operation. This could then be used to know which installation to acknowledge.
Thus, as soon as we have all the information in RAUC to tell that we have successfully booted and activated a distinct installation, then it would be straight-forward to wire this into rauc-hawkbit-updater.
In a typical implementation of RAUC it is the responsibility of the newly updated slots to mark their status good or bad.
rauc-hawkbit-updater to my knowledge does not support reporting success back to hawkbit after the newly updated slot has been validated via a boot or external test, rather it reports success immediately upon a ""successful"" install.
I would consider this a problem as it may falsely label a failed install as successful. This is made worse by Hawkbit's lack of API to update the recorded software version number. So not only is a failed install labeled as successful, Hawkbits is unaware of any rollback the target system has performed and will skip reinstall attempts because it thinks the current software is up to date.
See this other user with similar problems: eclipse-hawkbit/hawkbit#446
With SWUpdate's Hawkbit client, it's the responsibility of the updated OS to report a successful install... I think... or its reporting mechanism is broken.
Am I the only person seeing this problem or am missing something in my implementation?
Is it possible to have rauc-hawkbit-updater only inform hawkbit of a successful update after the update has been truly validated?
The text was updated successfully, but these errors were encountered: