Thud to Warrior Upgrade Documentation Flawed?

General Discussions
1

So, the process documented here appears to generate an artifact that will OTA update a previously deployed <warrior installation, resulting in an updated client/arti and a dual fs configuration, which is the intention. Perfect.

However, all the file system images generated for that same release, the ones that end up burned to bare metal during manufacturing, will not implement the dual fs config, they will continue to use /etc/mender/mender.conf, exclusively.

This results in a single version being released that is functionally different depending on whether it is deployed OTA or programed to a reel of chips during manufacturing.

Devices with the release programmed during manufacturing can not be OTA updated if the migration directives are removed from local.conf in future build/releases, despite that being the prescribed process.

If you would like to know what this looks like in practice, I can describe how this played out for us.

SLR-

2

Thanks for reporting @SuicidalLabRat.

You are right: devices flashed with that image will have single configuration setup and won’t be able to OTA update with >=warrior images that use split configuration feature. The workaround “migrates” the device from single to dual configuration using an state script, which is not run if you just flash a device but only if you OTA update a device.

Maybe it is not clear enough, but the workaround was meant to upgrade the already deployed fleet from thud to warrior, not to be used for freshly flashed devices.

Lluís