Using mender on Jetson Xavier NX emmc with Verity system partitions

[f-gia]

Hello,

We are trying to setup Mender on our Jetson Xavier NX eMMC. We noticed that after booting the device, not issuing mender commit, and rebooting, there is no rollback: the update is still there. We expected that the system would rollback after the first reboot, to protect against a corrupted update. What would be the actual expected behavior, and how can we implement our desired behavior?

Secondly, we would like to use read-only root file system partitions as verity targets to verify their integrity. We want to store the root hash of the verity tree in the /data partition, hence we need to alter the mender artifact produced by bitbake to include the new root hash to be written in the /data partition. Which part of the meta-mender-tegra layer should we alter accordingly?

[dwalkes]

Hi @f-gia

We noticed that after booting the device, not issuing mender commit, and rebooting, there is no rollback: the update is still there. We expected that the system would rollback after the first reboot, to protect against a corrupted update. What would be the actual expected behavior, and how can we implement our desired behavior?

What you are seeing is the behavior we've used for the mender implementation on Jetson devices. This does deviate from the standard mender behavior regarding rollback. You can find a related discussion at OE4T/meta-mender-community#8 (comment)

Regarding how to implement rollback, I think you'd need your own service (or modify an existing one) to do the rollback step if enough boot cycles have passed without -commit. You could use uboot's design as a reference and make the corresponding hacks on cboot to integrate to the existing Update Engine State Machine NVIDIA uses.

I haven't experimented with verity on mender myself so don't have a specific direction for you on that one.

[f-gia]

Could you point out where and how mender communicates with cboot to switch the boot partition before reboot?
As for the rollback, the current setup seems to work fine for us. Thank you.

[dwalkes]

It happens through the tegra-bootloader-update call at https://github.com/mendersoftware/meta-mender-community/blob/dunfell/meta-mender-tegra/recipes-mender/tegra-state-scripts/files/redundant-boot-install-script#L54 - see documentation here. This is a replacement for the nv_update_engine sequence described here.