I’ve been integrating mender in our product and I think I’m 99% done.
However I encounter a strange behavior which I cannot explain.
Allwinner S3 boot from eMMC
uboot at start sector of eMMC (not in partition table, boot command hardcoded with mender patches applied)
rootfsA at mmcblk2p1 (ro)
rootfsB at mmcblk2p2 (ro)
/data at mmcblk2p3 (rw)
I have a symlink in /var/lib to point at /data/mender to store persistent mender data.
Same for /etc/fw_env.config
fw_printenv works, also all points https://docs.mender.io/2.4/devices/yocto-project/bootloader-support/u-boot/integration-checklist work exactly as expected.
I’m booting from A. The mender daemon starts and connects to the server correctly. Once added in the admin interface and an update being scheduled, mender downloads the image and writes it to partition B. However, it does not change the u-boot config. Mender then reboots, and now after starting the service, mender changes the boot config to boot from B. On the server tool, I get “update successful”. Then nothing happens. If I now reboot manually, the system now boots correctly from B.
The same happens if I start a new update, just the other way around.
From my understanding, this behavior doesn’t make any sense. I would expect mender to temporarily boot to the other partition after the successful update, and if the update worked and mender daemon starts, it sets this partition as the permanent boot partition.
All my configs and u-boot patches are based on this repo: https://github.com/mendersoftware/buildroot-mender/tree/master/buildroot-external-mender
I used the mender package available in buildroot-2020-05.
You can find the persistent storage, including some logs of the updates here:
I just used the same rootfs generated for provisioning to create the artifacts.
Any help would be greatly appreciated!
Thanks and best regards