Mender_boot_part is not defined

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

update-store [Download_Enter] -> update-after-store [Download_Leave]

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.

Error: “mender_boot_part” not defined

It looks like your ArtifactReboot_Enter_50 script is doing something that required a variable called mender_boot_part. Hard to say exactly what.
Drew

@anishmonachan, which U-Boot version are you using?

You might be hitting this one, https://tracker.mender.io/browse/MEN-3970

How I can check the uboot version?
I had set a variable MENDER_BOOT_PART = "${MENDER_STORAGE_DEVICE_BASE}1" which seems to have no effect.

I think just running “version” at the UBoot prompt. Also, it normally displays the version in the header when it boots.

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

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.

Then this is the problem, https://tracker.mender.io/browse/MEN-3970

i dont know anything about your board, but can you run fw_printenv on the board to confirm the variables exist in uboot env?

fw_printenv | grep mender_boot_part

here is the ouptut

  bootcmd=run mender_setup; setenv distro_bootpart ${mender_boot_part}; setenv distro_bootpart_hex ${mender_boot_part_hex}; setenv devnum 0; setenv devtype "mmc"; setenv prefix /boot/; sysboot ${devtype} ${devnum}:${distro_bootpart_hex} any ${scriptaddr} ${prefix}extlinux/extlinux.conf; run mender_try_to_recover
mender_altbootcmd=if test ${mender_boot_part} = 1; then setenv mender_boot_part 30; setenv mender_boot_part_hex 1E; else setenv mender_boot_part 1; setenv mender_boot_part_hex 1; fi; setenv upgrade_available 0; saveenv; run mender_setup
mender_setup=if test "${mender_saveenv_canary}" != "1"; then setenv mender_saveenv_canary 1; saveenv; fi; if test "${mender_pre_setup_commands}" != ""; then run mender_pre_setup_commands; fi; if test "${mender_systemd_machine_id}" != ""; then setenv bootargs systemd.machine_id=${mender_systemd_machine_id} ${bootargs}; fi; setenv mender_kernel_root /dev/mmcblk0p${mender_boot_part}; if test ${mender_boot_part} = 1; then setenv mender_boot_part_name /dev/mmcblk0p1; else setenv mender_boot_part_name /dev/mmcblk0p30; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_uboot_root mmc 0:${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

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:

meta-mender-core/recipes-bsp/u-boot/patches/

and the defines in:

meta-mender-core/recipes-bsp/u-boot/patches/0002-Generic-boot-code-for-Mender.patch

The behavour @anishmonachan is seeing is because of this commit which exists in 2.3.0 client.

It turned out that the updated syntax is not backwards compatible (not at least to beginning of time :slight_smile: ) 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.
  • stay on 2.2.x Mender client

Thanks for your suggestion @mirzak .
But the question is 2.2.x supports mender delta update or not?

Not the version of delta updates that is available in Mender Enterprise, I believe. So I think you are left with one option.

1 Like

@dellgreen I went back to the mender tutorial for yocto. I saw that I have to add

MENDER_FEATURES_ENABLE_append = " mender-uboot"

in local.conf to enable mender uboot. After that I have following output

bootcmd=run mender_setup; setenv distro_bootpart {mender_boot_part}; setenv distro_bootpart_hex {mender_boot_part_hex}; setenv devnum 0; setenv devtype “mmc”; setenv prefix /boot/; sysboot {devtype} {devnum}:{distro_bootpart_hex} any {scriptaddr} {prefix}extlinux/extlinux.conf; run mender_try_to_recover mender_altbootcmd=if test {mender_boot_part} = 1; then setenv mender_boot_part 30; setenv mender_boot_part_hex 1E; else setenv mender_boot_part 1; setenv mender_boot_part_hex 1; fi; setenv upgrade_available 0; saveenv; run mender_setup
mender_boot_part=1
mender_boot_part_hex=1
mender_setup=if test “{mender_saveenv_canary}" != "1"; then setenv mender_saveenv_canary 1; saveenv; fi; if test "{mender_pre_setup_commands}” != “”; then run mender_pre_setup_commands; fi; if test “{mender_systemd_machine_id}" != ""; then setenv bootargs systemd.machine_id={mender_systemd_machine_id} {bootargs}; fi; setenv mender_kernel_root /dev/mmcblk0p{mender_boot_part}; if test {mender_boot_part} = 1; then setenv mender_boot_part_name /dev/mmcblk0p1; else setenv mender_boot_part_name /dev/mmcblk0p30; fi; setenv mender_kernel_root_name {mender_boot_part_name}; setenv mender_uboot_root mmc 0:{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

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, :slight_smile:

@mirzak @dellgreen
patching and adding variable MENDER_FEATURES_ENABLE_append = " mender-uboot" solved this issue :slight_smile:

Thank you very much :slight_smile:

1 Like