I have been struggling with this issue for a while, I would really appreciate the guidance.
I am trying to integrate mender 2.3 with the board ts-4900, it has an older u-boot version 2014.10, after I deploy a new artifact, the deployment process will go all the way to 99%, then the board will fail to re-boot correctly. After checking the environment variables I found that the following two environment variables will disappear at the end of the update process ( mender_boot_part and upgrade_available), and because of that the board will not be able to re-boot correctly at the end of the upgrade. I already checked that these two variables were there before the update process. any thoughts?
Probably something wrong with the integration of U-Boot or the configuration of the U-boot environment.
I would suggest you to run trough the following,
Which can help pin-point the issue.
Thank you for the prompt response, ok, I will go through the checklist and let you know the result
I have followed the Integration checklist, I could do all the steps with no issues. the only difference is that I will need to run the fw_printenv and fw_setenv as a sudo, if I don’t use sudo, I will get and error that said " Error opening lock file / var / lock / fw_printenv . lock" .
I was able to track the issue to the following function " InstallUpdate()" in the file https://github.com/mendersoftware/mender/tree/master/installer/ dual_rootfs_device.go,
after the execution of the following line of that function, the two variables mender_boot_part and upgrade_available will disappear but not bootcount:
err = d.WriteEnv(BootVars{“upgrade_available”: “1”, “mender_boot_part”: inactivePartition, “mender_boot_part_hex”: inactivePartitionHex, “bootcount”: “0”})
I would appreciate any guidance that would bring me closer.
i would try writing and reading back the exact same variables i.e upgrade_available, mender_boot_part, mender_boot_part_hex manually and reboot to ensure that its not related to these in particular. Make sure you keep the latter two variables contain the same value when you change them
That should narrow it down to a uboot env issue or mender/uboot env issue
It should be noted that it looks like the mender code is subtly using fw_setenv in slightly different way than the checklist does. So you could also try testing the piping the key-value pairs to it to replicate what mender is doing.
Example:
echo "upgrade_available=1" | fw_setenv -s -
1 Like
I just encountered a similar issue when migrating from mender 1.7 to mender 2.2.
The commit “MEN-3684: Switch to fw_setenv script syntax which libubootenv supports.” (5213de3916433dcd2d18a4495ecdf62b47124343) seems to have caused the issue by changing the syntax to set U-Boot env variables. It looks like some variants of fw-utils don’t support the fw_setsenv var=value syntax, thus leading to the variables being erased and the device not being able to boot after an update installation.
Updating the checklist in the doc might help to pinpoint the issue!
2 Likes
Can confirm my products are on older u-boot-fw-utils-mender-auto-provided package which doesn’t support the script option, but also using an older mender client prior to this change, is why i don’t see this issue myself yet.
Thank you vhubert, yes that was the issue, I removed that commit and re-built mender locally and things worked, so as you stated fw_setenv var=value will silently assign nothing to that variable and then that variable will disappear. the only way to assign env variables in my flavour of ubuntu is by doing fw_setenv var value. with no equal sign.
Some additional information on this can be found here, https://tracker.mender.io/browse/MEN-3970
1 Like