# Mender variables are updated when mender installation is not completed

**URL:** <https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278>\
**Category:** General Discussions\
**Tags:** yocto, sumo, nxp\
**Created:** [October 18, 2023, 5:14pm UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278 "2023-10-18T17:14:30Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![achyuthr](https://avatars.discourse-cdn.com/v4/letter/a/53a042/32.png) [@achyuthr](https://hub.mender.io/u/achyuthr)\
**Post date:** [October 18, 2023, 5:14pm UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/1 "2023-10-18T17:14:30Z")

</div>

Dear Community,

I’m using Yocto SUMO version meta-mender for our FOTA update.

We are performing negative scenario where we are performing abrupt power off of the device during OS fota installation still in progress. After device boot up we observed that **mender\_boot\_part** , **mender\_boot\_part\_hex** variables updated to boot from next partition. But the new partition contents were not completely written by mender as there was abrupt power off during the installation was in progress.  
But question is why was the mender\_boot\_part, mender\_boot\_part\_hex variables updated here though the new partition was not completed written. Please assist. Thanks

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [October 23, 2023, 11:39am UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/2 "2023-10-23T11:39:49Z")

</div>

Hello @achyuthr,

We have identified one bug in our sync code, which I have posted [here](https://github.com/mendersoftware/mender/pull/1442). However, hitting this bug is quite rare. Could you post me the line from your client log which contains “Native sector size of block device”?

---

<div class="post-metadata">

**Author:** ![achyuthr](https://avatars.discourse-cdn.com/v4/letter/a/53a042/32.png) [@achyuthr](https://hub.mender.io/u/achyuthr)\
**Post date:** [October 23, 2023, 3:12pm UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/3 "2023-10-23T15:12:58Z")

</div>

> [@achyuthr](#):
>
> **mender\_boot\_part\_hex**

## Hello @kacf , Below is the log snippet of the client which contains “Native sector size”

## INFO[0000] native sector size of block device /dev/mmcblk0p3 is 512, we will write in chunks of 1048576 module=dual\_rootfs\_device

Now coming the scenario:  
We have powered off abruptly during the mender installation phase. So the installation could be for example 20% complete or 60% complete. And it may not be at the very end of mender installation. Since installation is partially complete, we cannot boot from the new partition as kernel or rootfs packages may not be present.

So question is:  
Would the mender\_boot\_part, mender\_boot\_part\_hex be updated to boot from new partition, if abruptly powered off during completion of only 60% or 20% (mender installation)?

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [October 24, 2023, 4:48am UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/4 "2023-10-24T04:48:32Z")

</div>

Thanks for the log output, it’s pretty unlikely you are affected by the mentioned bug then.

Mender does not change `mender_boot_part` and `mender_boot_part_hex` until all of the download is both finished and synced to disk. Is it possible you have any state scripts, either in `/etc/mender/scripts`, or attached to the artifact, which could change the variables?

---

<div class="post-metadata">

**Author:** ![achyuthr](https://avatars.discourse-cdn.com/v4/letter/a/53a042/32.png) [@achyuthr](https://hub.mender.io/u/achyuthr)\
**Post date:** [October 26, 2023, 10:53am UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/5 "2023-10-26T10:53:26Z")

</div>

@kacf ,

we have not modified the state scripts that would change these variables.  
Thanks you

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [October 26, 2023, 11:35am UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/6 "2023-10-26T11:35:12Z")

</div>

Ok, then I will need more information, since I can’t immediately see what would cause the problem.

Tell me more about your setup:

1. Are you using Mender in daemon mode or standalone mode?
2. Can you post the following information:
  1. The output from this command, before you start the update:

```bash
grub-mender-grubenv-print || fw_printenv; mount

```

  2. The commands you use to invoke the update, or the steps in the UI, if that’s what you use.
  3. After the deployment, the output from the same command again:

```bash
grub-mender-grubenv-print || fw_printenv; mount

```

3. Can you post the deployment log? In standalone mode, this is just the output from the command. In daemon mode, the log can be found at `/var/lib/mender/deployments.0000.<UID>`.

---

<div class="post-metadata">

**Author:** ![achyuthr](https://avatars.discourse-cdn.com/v4/letter/a/53a042/32.png) [@achyuthr](https://hub.mender.io/u/achyuthr)\
**Post date:** [November 2, 2023, 7:02am UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/7 "2023-11-02T07:02:52Z")

</div>

Hi @kacf ,

1. we are using the Mender in standalone mode.

2. 
  1. we have not captured the fw\_printenv output before the update.
  2. mender install command below:  
mender -log-level debug -log-file -install 
  3. Since the device was hung at uboot, we were able get the “printenv” from Uboot  
altbootcmd=run mender\_altbootcmd; run bootcmd  
baudrate=115200  
board\_name=CCU  
board\_rev=iMX8DX  
boot=container0  
boot\_version=0xD000  
bootargs=console=ttyLP0,115200 earlycon=lpuart32,0x5a060000,115200 rootwait rootfstype=ext4 ro  
bootcmd=run mender\_setup; setenv bootargs root=${mender\_kernel\_root} ${bootargs}; if test “${fdt\_addr\_r}” != “”; then load ${mender\_uboot\_root} ${loadaddr\_os\_cntr} /boot/${os\_container}; fi; auth\_cntr ${loadaddr\_os\_cntr}; ${mender\_boot\_kernel\_type} ${loadaddr} - ${fdt\_addr\_r}; run mender\_try\_to\_recover  
bootcmd\_mfg=run mfgtool\_args;if iminfo ${initrd\_addr}; then if test ${tee} = yes; then bootm ${tee\_addr} ${initrd\_addr} ${fdt\_addr}; else booti ${loadaddr} ${initrd\_addr} ${fdt\_addr}; fi; else echo “Run fastboot …”; fastboot 0; fi;  
bootcount=1  
bootdelay=1  
bootlimit=1  
commit\_atf=1cb68fa  
commit\_mkimage=dd023400  
commit\_scfw=a5df0112  
commit\_secofw=d1489a99  
ethaddr=00:01:02:03:04:05  
ethprime=eth0  
fastboot\_dev=mmc0  
fdt\_addr\_r=0x83000000  
fdt\_file=fsl-imx8dx-ccu.dtb  
fdt\_high=0xffffffffffffffff  
fdtcontroladdr=bda8d030  
initrd\_addr=0x83100000  
initrd\_high=0xffffffffffffffff  
kboot=booti  
kernel=Image  
loadaddr=0x80280000  
loadaddr\_m4=0x88000000  
loadaddr\_m4\_cntr=0x85000000  
loadaddr\_os\_cntr=0x86000000  
loadm4image\_0=load mmc 0:6 ${loadaddr\_m4\_cntr} ${m4\_0\_image};auth\_cntr ${loadaddr\_m4\_cntr}  
m4\_0\_image=m4\_ccu\_app\_signed.bin  
m4boot\_0=run loadm4image\_0; dcache flush; bootaux ${loadaddr\_m4} 0  
mender\_altbootcmd=if test ${mender\_boot\_part} = 2; then setenv mender\_boot\_part 3; setenv mender\_boot\_part\_hex 3; else setenv mender\_boot\_part 2; setenv mender\_boot\_part\_hex 2; fi; setenv upgrade\_available 0; saveenv; run mender\_setup  
mender\_boot\_kernel\_type=booti  
mender\_boot\_part=3  
mender\_boot\_part\_hex=3  
mender\_check\_saveenv\_canary=1  
mender\_dtb\_name=fsl-imx8dx-ccu.dtb  
mender\_kernel\_name=Image  
mender\_pre\_setup\_commands=run m4boot\_0;ahab\_status  
mender\_saveenv\_canary=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; setenv mender\_kernel\_root /dev/mmcblk0p${mender\_boot\_part}; if test ${mender\_boot\_part} = 2; then setenv mender\_boot\_part\_name /dev/mmcblk0p2; else setenv mender\_boot\_part\_name /dev/mmcblk0p3; 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  
mender\_try\_to\_recover=if test ${upgrade\_available} = 1; then reset; fi  
mender\_uboot\_boot=mmc 0:1  
mender\_uboot\_dev=0  
mender\_uboot\_if=mmc  
mfgtool\_args=setenv bootargs console=${console},${baudrate} rdinit=/linuxrc clk\_ignore\_unused  
os\_container=os\_cntr\_signed.bin  
sec\_boot=yes  
soc\_type=imx8qxp  
stderr=serial@5a060000  
stdin=serial@5a060000  
stdout=serial@5a060000  
upgrade\_available=0

3. since device was hung at Uboot, we could not get the deploment logs. we had to reflash the device and hence we lost the logs.

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [November 3, 2023, 7:19am UTC](https://hub.mender.io/t/mender-variables-are-updated-when-mender-installation-is-not-completed/6278/8 "2023-11-03T07:19:19Z")

</div>

I noticed that `upgrade_available=0` exists in the output you posted. This is unexpected for an update which has not booted successfully yet.

The order is supposed to be:

1. Install update.
2. Bootloader environment is switched to;

```auto
bootcount=0
mender_boot_part=3
upgrade_available=1

```

3. Reboot.
4. Bootloader switches environment to:

```auto
bootcount=1
mender_boot_part=3
upgrade_available=1

```

5. Boot proceeds.
  - If boot fails, bootloader switches environment to:

```auto
bootcount=1
mender_boot_part=2
upgrade_available=0

```

  - If boot succeeds instead, `mender commit` switches the environment to

```auto
bootcount=1
mender_boot_part=3
upgrade_available=0

```

As you can see, the only scenario where the environment is switched to what you have in your log, is when Mender has successfully run from the new partition. Bootloader environment updates are atomic and checksummed, so I don’t think partial updates can explain this. This leads me to believe there is something wrong in the bootloader setup itself, but it’s difficult to be specific. You might want to inspect the environment at various points to make sure it is as expected.

Sorry I can’t be of more help.