Fine with me: that's why I originally said that I'm not sure if it is intended behavior or not... as long as the log warning is clear it sounds good to me to keep this behavior.
Kristian Amlie June 20, 2017 at 9:25 AM
Edited
: After talking about this, we decided that the risk of not being able to do updates counts higher than the risk of deploying the wrong update to a device that doesn't have the device_type file. Deploying a new update may be your only remedy if you end up in this situation, so we should not prevent that. Because of this we will allow such updates after all, with warnings of course.
Kristian Amlie June 6, 2017 at 7:41 AM
No update yet, but this is on our backlog of things to fix.
Felix Ruess June 2, 2017 at 2:42 PM
Any updates here? Should I retest this with 1.1.0b1 or hasn't anything been done here anyway?
Kristian Amlie May 22, 2017 at 8:07 AM
It is not intended behavior! It would be quite unsafe for Mender to continue in this mode.
, I suggest the following behavior:
If device_type is unreadable when running a stable version (no update in progress), keep running and reporting to the server, but refuse all upgrades until the file is restored.
If an upgrade is in progress and device_type is unreadable, fail the update and roll back.
When running the mender client in standalone mode and the device_type file is not found it only prints an error, but continues with the update:
time="2017-05-17T16:40:05Z" level=error msg="Can not read manifest data." module=mender
Not sure if this is intended behavior or not...