Hello,
I’m using yocto based mender client.
Recently I have switched from mender v2.2 to mender v2.3 to test delta updates.
The mender update is failing with following logs
2020-09-29 14:26:51 +0000 UTC info: State transition: update-after-store [Download_Leave] → update-install [ArtifactInstall]
2020-09-29 14:26:51 +0000 UTC info: Enabling partition with new image installed to be a boot candidate: 30
2020-09-29 14:26:51 +0000 UTC info: State transition: update-install [ArtifactInstall] → reboot [ArtifactReboot_Enter]
2020-09-29 14:26:51 +0000 UTC info: Collected output (stderr) while running script /var/lib/mender/scripts/ArtifactReboot_Enter_50
Starting nvidia mender enter reboot redundant boot steps
Enabling A/B update mode using nv_update_engine
Nvidia A/B-Redundancy Update tool Version 1.2
enabling A/B redundancy
A/B Redundancy has been enabled.
Since I’m using jetson tx2, I’m not able to look at the boot info. From the recipe, I can see that I’m using u-boot 2016.07.
To tell about more about my use case, I’m looking to upgrade mender version 2.3 to test delta updates. Everything was working well with version 2.2.0 which I’ve been using before. Do you think the version v2.2.1 supports delta update or if it is a requirement to use v2.3? I’m using the warrior branch
Whilst there is code there to set the variables, I’m not seeing any actual defined uboot variables.
for example my output on uboot 2017.03:
mender_altbootcmd=if test ${mender_boot_part} = 1; then setenv mender_boot_part 2; setenv mender_boot_part_hex 2; else setenv mender_boot_part 1; setenv mender_boot_part_hex 1; fi; setenv upgrade_available 0; saveenv; run mender_setup
mender_boot_part=2 <<<< here
mender_boot_part_hex=2 <<< and here
mender_setup=if test "${mender_pre_setup_commands}" != ""; then run mender_pre_setup_commands; fi; setenv mender_kernel_root /dev/mmcblk1p${mender_boot_part}; if test ${mender_boot_part} = 1; then setenv mender_boot_part_name /dev/mmcblk1p1; else setenv mender_boot_part_name /dev/mmcblk1p2; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_uboot_root mmc 1:${mender_boot_part_hex}; setenv mender_uboot_root_name ${mender_boot_part_name}; setenv expand_bootargs "setenv bootargs \\"${bootargs}\\""; run expand_bootargs; setenv expand_bootargs; if test "${mender_post_setup_commands}" != ""; then run mender_post_setup_commands; fi
So to me, it doesn’t look like the uboot variables are getting defined in yours. Given that you are running and older uboot like myself, I suggest going back and checking that the meta-mender-core uboot patches are getting applied correctly. For example in mine they were not so I had to analysis what the patches were doing one by one and rework the patches in my own yocto layer to work with my uboot.
It look like the defines for my version of meta-mender are in:
It turned out that the updated syntax is not backwards compatible (not at least to beginning of time ) and I am pretty sure that 2016.07 U-Boot does not support this syntax.
What happens when U-boot does not support that syntax, the variable is cleared instead of set, which is explains why they are missing. We do not yet have a 2.3.x release with a fix, but there will be one I assume as it is being worked on here, https://tracker.mender.io/browse/MEN-3970
The options you have are:
patch Mender client in your environment, and revert the mentioned commit.
yes that looks better now from the outset, i also have “mender-uboot” set in “MENDER_FEATURES_ENABLE_append”, After all that you also now need to watch out for/fix the subsequent problem that @mirzak has pointed out which looks like they will get erased again when you use the mender-client 2.3.x,
) and I am pretty sure that 2016.07 U-Boot does not support this syntax.