I’m using Yocto SUMO version meta-mender for our FOTA update.
We are observing a strange issue. i.e., even after successful FOTA, i mean partition is switching from old partition to new partition. But, the uboot environment variables “mender_boot_part” & “mender_boot_part_hex” are not getting updated after this. Due to this, partition is rolling back after another power cycle (reboot).
For example : Assume we are in partition-1(old software) and performed FOTA. After power cycle the partition value is updated to partition-2(new software). But the uboot env variable are like this : mender_boot_part = 1 & mender_boot_part_hex = 1. After another power cycle, due to mender variables are not getting updated, the partition rolls back to partition-1(old software).
Can you help here to find the reason why this uboot environment variable “mender_boot_part” & “mender_boot_part_hex” are not getting updated ?
Thanks for getting in touch! From a very superficial point of view, it sounds like writing to the u-boot environment fails. Can you please share the mender-client logs on such an update process in order to diagnose?
For better understanding, which board is this? Which integration steps are you following?
Greetz,
Josef
PS: on a side note, sumo is end of life since years by now, so you should definitely upgrade, if only for security reasons.
I see you are using standalone mode. Did you run mender commit after booting into the new partition? This is what makes the change permanent. If you did, perhaps you could post the log from mender --log-level debug commit as well.
We observed a new behavior recently. It is like this… After performing FOTA and power cycle (reboot), the partition is switching to new partition. After booting from the new partition, we performed 30 reboots without performing mender commit. Here, the device is booted from the latest partition in 29 iterations out 30 iterations. But, in one iteration we observed the roll back which means the device booted with old partition. Why it is so ?
Does it not required commit after FOTA ?
If yes, then why there is no roll back observed in our test 29 times ? why only one time ?
What technically mender commit does ?
Under which logical conditions mender will update “mender_boot_part” & “mender_boot_part_hex” u-boot environment variables back to old partition values ?
I’m really sorry, but given the facts that you are on a
very outdated Yocto version (Sumo is unmaintained since 2019)
presumably outdated Mender client version - you didn’t name it, but the last one we had on Sumo is 2.2.x
using it in standalone mode with custom scripting around it
means that we are dealing with a use case that is highly specific to you.
If you need help in moving forwards with either the client integration/migration in your project, or moving to a newer Yocto release respectively a managed solution, then please get in touch with us directly for professional services.
Have you got any state scripts installed that could be causing a race condition that may be being run, as I believe from 2.0.0 even in standalone mode the client will run them.
I myself have older products running sumo and mender client that doesn’t exhibit the problems you mention, however I have backported mender 2.5.0 into my sumo builds for those, so could be related to older client, or mender uboot integration code.
we are having 2 sets of u-boot environmental variables in the rpmb area. So when we perform the fota one set gets updated from mender.
one observation is seen that after about 100 iteration. Though the mender has updated one of the set, fw_printenv command is referring the old set.
we are using fw_printenv to decide whether the partition has switched or not. Since fw_printenv is pointing to old set of RPMB, “mender_boot_part” and “mender_boot_part_hex” values remains the same. hence we are not going for commit.
is this expected behavior of fw_printenv?
can we use “mount” command instead of fw_printenv? for us “mount” command is giving the updated partition value every time.
do you recommend any other way to get the updated partition value?