Report by user on mailing list:
I've run into an issue that I consider a bug:
- I'm pre-authorizing devices with a single key-value pair for identification (serialnumber).
- This works (so far so good).
- I've reflashed the device.
- Starting Mender in this scenario results in a weird state: Mender claims that a device is pending as it shows up in the 'pending' section of the UI. However, looking in 'devauth' and 'admission' shows in the first that the device is accepted, and in the second one pending.
I can reproduce this without flashing the device, but simply by removing the 'mender-store' from the device (which is the same as reflashing it).
To me this looks like a bug, because the scenario can happen: a device is returned to the dealer because storage is broken. The dealer replaces the storage part (hence the 'reflash'), but the device id (serialnumber in our case) is the same.
For now I'm going to 'fix' this by adding another key-value pair to the identification next to the serial number and use an UUID for this. In this case on re-flash for Mender it's just a new device.
Would be great if someone from the Mender team can comment on this.
Another interesting comment from the same thread (screenshots attached):
I replayed stuff with some screenshots to show:
1. pre-authorize a device with a single kv pair (in this case: 'serial'). --> SCREENSHOT 1
2. start mender client on the specific device with a key already located in /data/mender/mender-agent.pem --> SCREENSHOT 2
In this scenario you see in the Mender UI that the device is gone in the 'preauthorized list' and shows up under devices.
3. stop mender client on device
4. remove /data/mender/mender-store*
5. start mender client on devce --> SCREENSHOT 3
Now you see the bizarre phenomenon that the Mender UI states that there's one device is pending (which is another device actually pending), but in the list you see 2 devices!
You can also see that the key and id are the same.
Full mailing list thread can be found here
I have also been able to re-produce this quite easily following the above user notes.
I have also confirmed that problem is resolved on "master" branch, probably due to
MEN-1728 being merged.
Question is what can we do for 1.6.x?