First of all thanks for digging in to this and reporting back your findings. The findings are relevant and actually also explains some things that I have experienced as well but never understood (why moving SD card from RPi3 Model B to B+ did not work)
I am not aware of any alternatives to
saveenv and you always write the whole environment in one go, this is also something that makes changes to the environment atomic and this is important to keep intact.
Right now I’m working on a patch for u-boot for the Mac address thing, but I’m worried about what other side effects happen due to doing the saveenv. Right now we’re working on finding and removing all Raspberry Pi 3B’s from the office so we don’t have the cross-over failure.
The purpose of the
saveenv command is to detect inconsistencies in environment configuration between U-boot and the user-space. This is what
mender_saveenv_canary=1 is used for and this is the purpose of the
saveenv. The Mender client will actually check the presence of this variable and complain if it is not there. That is at least my understanding as I have not looked in to these specific parts in a while.
Note that the
saveenv is only executed once, during the first boot.
Trying to run
env default -a before calling
saveenv will force it to re-write the U-boot environment on each boot, this is not desirable as it will cause “wear” on the SD card and increase chances of breaking blocks. Something to avoid to increase longevity of your device.
With all that said, I do not really see any major side-effects/downsides of this behaviour expect that you might not be able to move an SD card that has booted once from a RPi3 B+ to RPi 3 B. But I would argue that every time you move the SD card to between devices there are other reasons on why you would re-provision it again to get a fresh start, even if it is from RPi3 B+ to RPi3 B+.
One reason is the device identity which is used by Mender and this is typically a hardware bound identifier. Now in this specific case it is using the defaults (MAC address, which was carried over due to the U-boot environment) but this is something that is configurable and might as well have been something else that is not related to the U-boot environment.
And would not be to worried about the
saveenv causing other problems as this is the environment that your device boots with and the result of the
saveenv will only save it to disk, but it would otherwise contain these variables even if we did not do the saveenv.