Assigning artifacts after successful update again

[EugenWiens]

Hi, how is the right procedure when after a successful update I try to assign the artifact again.

My problem is: The system that is updated have redundancy boot mechanism. When the system detect a problem with the current software version (V2) its switch back to the last one (V1). If that happening and the update to V2 comes from hawkbit the hawkbit will never again deliver the version V2.

I tried to assign the artifact to the device again in the Deployment Management view but I get a notification that the version is already installed. Is it possible that the device reports his software version for this decision ? What means the options forced, Soft and time Forced

[michahirsch]

Hi @EugenWiens ,

There are two questions in this issue.

1. Yes, hawkBit is checking if the installed-DistributionSet is already set to the device and won't create an update-action for it if so. There is currently no mechanism to set a fix installed-DistributionSet There is an issue which describes the functionality that a device can tell it's installed version. See: https://github.com/eclipse/hawkbit/issues/242

2. The options forced and soft are meta-data for the device. The interpretation is device specific actually. Use-cases are for example in a case of a soft update you want to inform a user that there is an update available, or a soft update can indicate that the device can download and install the update when resources are available. A forced update could indicate that critical security updates needs to be immediately installed without user-interaction for example. time-forced only means that you want to execute an update as soft but e.g. in a case the update is not installed after a period of time hawkBit switching the update automatically into forced.

Cheers, Michael

[sbabic]

On 28/02/2017 11:22, Michael Hirsch wrote:

Hi @EugenWiens https://github.com/EugenWiens ,

There are two questions in this issue.

Yes, hawkBit is checking if the |installed-DistributionSet| is
already set to the device and won't create an update-action for it
if so. There is currently no mechanism to set a fix
|installed-DistributionSet| There is an issue which describes the
functionality that a device can tell it's installed version. See:
#242 <https://github.com/eclipse/hawkbit/issues/242>

The options |forced| and |soft| are meta-data for the device. The
interpretation is device specific actually. Use-cases are for
example in a case of a |soft| update you want to inform a user that
there is an update available, or a |soft| update can indicate that
the device can download and install the update when resources are
available. A |forced| update could indicate that critical security
updates needs to be immediately installed without user-interaction
for example. |time-forced| only means that you want to execute an
update as |soft| but e.g. in a case the update is not installed
after a period of time hawkBit switching the update automatically
into |forced|.

—

My work-around: I created two distributions in the GUI and this let me assign them again to the device. I could also assign first the old one, and without waiting, I assign next the new one. But I agree that it should be handled in some way.

The Hawkbit server does not check the installed version on the device and relies on the value in the DB. But the device can fallback to the older for a lot of reasons (corrupted fs ? crash ? something else ?), and it could send the installed release with the configData (I know, this is not evaluated now by the server). Or with a new API, I do not know.

Is this an issue that can be changed in future ? A mismatch between the DB and what is running on the devices is really a use case.

Best regards, Stefano

-- Meet DENX at the Embedded World Trade Show 14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581

===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: [email protected]

[EugenWiens]

A feedback channel will be great. That the DB is out of sync with the real software version is a problem in some embedded update concepts. e.g. second way for an update ( USB-Stick ) or redundancy boot.

[sbabic]

On 28/02/2017 13:26, Eugen Wiens wrote:

A feedback channel will be great. That the DB is out of sync with the real software version is a problem in some embedded update concepts. e.g. second way for an update ( USB-Stick ) or redundancy boot.

IMHO this is a problem that can always happen even if we do not provide a second update source (in that case, it is clear !).

But even with a dual-copy concept and updating only from Hawkbit, there are cases where the board fallbacks to the previous version.

And the server cannot be absolutely sure about what is running on the board. I do not know if a customer can replace a broken board with another with same tenant / ID, but if this happens, it is another case.

Anyway, I think more about runtime errors, such as filesystem corruption (due maybe to software errors), or runtime conditions that avoid the current software to run. In such cases, a fallback is often implemented, and then the device is not aligned with Hawkbit's database.

Regards, Stefano

-- Meet DENX at the Embedded World Trade Show 14 Mar - 16 Mar 2017, Nuremberg Trade Fair Centre, Hall 4, Booth 581

===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: [email protected]

[michahirsch]

yeah, there are use-cases where hawkBit does not know about the installed version of a device (e.g. also in a plug'n play scenario where the device first time registered at hawkBit server), the truth which software is installed is always on the device.

So in general it would be good if a device could tell hawkBit which version is currently installed. Problem though is that hawkBit only knows about distribution-sets and a device is not distribution-set aware. There is some tricky parts to solve so in case a device tells hawkBit installedVersion=1.0.2 which distribution set belongs to that version. So the issue #242 I guess explaining this scenario.

[kaizimmerm]

I think what needs to be done after #242 is that devices by DDI or DMF as well can report offline updates by identifying DS by name, version.