upgrade_available flag doesn't retain its value after reboot

[hunter hu]

Hi,

I have a strange failure when upgrading with mender.  Everything goes through well, but the update failed because upgrade_available u-boot env variable reset to 0 after reboot, 

2017-12-06 01:25:01 +0000 UTC debug: Inactive partition: /dev/mmcblk0p3 2017-12-06 01:25:01 +0000 UTC debug: Marking inactive partition (/dev/mmcblk0p3) as the new boot candidate. 2017-12-06 01:25:01 +0000 UTC info: Enabling partition with new image installed to be a boot candidate: 3 2017-12-06 01:25:01 +0000 UTC debug: Marking inactive partition as a boot candidate successful.

But after reboot, the u-boot variable value 1 is not retained:

2017-12-06 01:25:02 +0000 UTC info: rebooting device 2017-12-06 01:25:53 +0000 UTC debug: handling state after reboot 2017-12-06 01:25:53 +0000 UTC info: State transition: after-reboot [ArtifactReboot_Leave] -> update-verify [ArtifactReboot_Leave] 2017-12-06 01:25:53 +0000 UTC debug: handle update verify state 2017-12-06 01:25:54 +0000 UTC debug: Have U-Boot variable: upgrade_available=0 2017-12-06 01:25:54 +0000 UTC debug: List of U-Boot variables:map[upgrade_available:0] 2017-12-06 01:25:54 +0000 UTC error: update info for deployment 0bccbf0d-a1b0-4c00-af7c-ecfcfe61cc74 present, but update flag is not set; running rollback image (previous active partition)

Any idea where to look at?

many thanks,

Hunter

[Kristian Amlie]

After rebooting, can you stop it at the U-Boot prompt and run
"printenv"? You should be able to see the upgrade_available variable set
to 1 there. If not there may be a problem that U-Boot and the fw-utils
user space tools don't agree on where the environment offsets are.

--
Kristian

[hunter hu]

Thanks for the tips, Kristian.

What is strange is that if I manually do a "sudo fw_setenv upgrade_available 1" and reboot it, the upgrade_available value is retained across reboot, it seems when mender client is doing it, value 1 is not retained across reboot.

My /etc/fw_env.conf is configured right if I can manually set it.

Any chance mender client is using something different?

-Hunter

[Kristian Amlie]

On 07/12/17 13:14, hunter hu wrote:
> Thanks for the tips, Kristian.
>
> What is strange is that if I manually do a "sudo fw_setenv
> upgrade_available 1" and reboot it, the upgrade_available value is
> retained across reboot, it seems when mender client is doing it, value 1
> is not retained across reboot.
>
> My /etc/fw_env.conf is configured right if I can manually set it.
>
> Any chance mender client is using something different?

No, it's calling more or less that exact command I think.

Maybe the path is wrong. Can you call these two commands on the device
and make sure that the tool is in the path?

which fw_setenv
cat /proc/`pgrep mender`/environ | xargs -0 -n1 echo | grep ^PATH=

--
Kristian

> --
> You received this message because you are subscribed to the Google
> Groups "Mender List mender.io" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mender+un...@lists.mender.io
> <mailto:mender+un...@lists.mender.io>.
> To post to this group, send email to men...@lists.mender.io
> <mailto:men...@lists.mender.io>.
> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.

[greg.di...@gmail.com]

Are you sure this is not related to: https://groups.google.com/a/lists.mender.io/forum/#!searchin/mender/fsck/mender/wi1TGloJ-nc/Pb9cYCp3CAAJ

Look very carefully at your boot-up process after applying an update, and verify if fsck is running (it can be hard to notice)

> an email to mender+unsubscribe@lists.mender.io

> <mailto:mender+unsubscribe@lists.mender.io>.

> To post to this group, send email to men...@lists.mender.io
> <mailto:men...@lists.mender.io>.

> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.

--
You received this message because you are subscribed to the Google Groups "Mender List mender.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mender+unsubscribe@lists.mender.io.
To post to this group, send email to men...@lists.mender.io.

[hunter hu]

Thanks for all the replies and hints, I appreciate that.

It turned out it is our watchdog on the SoC reset the board that interrupts the whole mender mechanism, and mender_altbootcmd kicks in and reset upgrade_available flag back to 0.

-Hunter

> an email to mender+un...@lists.mender.io

> <mailto:mender+un...@lists.mender.io>.

> To post to this group, send email to men...@lists.mender.io
> <mailto:men...@lists.mender.io>.

> Visit this group at
> https://groups.google.com/a/lists.mender.io/group/mender/.

--
You received this message because you are subscribed to the Google Groups "Mender List mender.io" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mender+un...@lists.mender.io.