Skip to:
Circumstances still under investigation.
Some times the Artifact created via snapshot is unusable as it will result in a failed update.
Relevant logs from the server side:
From the serial console, it can be seen that the device reboots twice: once into the target partition and then rollback into the original partition.
Creating a new Artifact with from the same snapshot command resulted in a successful deployment.
In effect, this fix made mender-artifact incompatible with Mac OS. See related bug
Cherry-pick here: https://github.com/mendersoftware/mender-artifact/pull/325
After experimenting a bit more, I have verified that touching a dummy file in the "broken" Artifact (in effect, triggering a fsck on the filesystem image) fixes the issue. I have been able to reliably reproduce the issue and the fix.
Great hunch !
PR here: https://github.com/mendersoftware/mender-artifact/pull/324
I believe it is because the boot loader rolls back, not Mender. Consider this state flow:
For a "normal" rollback it would be:
So it is behaving correctly (well, expected at least) in that regard. The question is what happens between reboot number one and two?
Attached the full logs from the Mender server and the serial console.
By looking closer to the serial console log I can see:
Mender running in partition /dev/mmcblk0p3, installing artifact in /dev/mmcblk0p2
Download complete
Boot into /dev/mmcblk0p2
Reboot (rollback?)
Boot into /dev/mmcblk0p3
Rebot again (why?)
Report deployment failure to server
Circumstances still under investigation.
Some times the Artifact created via snapshot is unusable as it will result in a failed update.
Relevant logs from the server side:
From the serial console, it can be seen that the device reboots twice: once into the target partition and then rollback into the original partition.
Creating a new Artifact with from the same snapshot command resulted in a successful deployment.