Mender client cannot update properly and loses connection to local mender server after rebooting

Hi! I’ve a problem with my mender setup.

I am using a board with iMX8, with eMMC and I’ve built the image using yocto.

here is the mender-set.conf that is used inside the image:
Machine and artifact settings

MENDER_ARTIFACT_NAME = “dev-varianta-69”
MENDER_DEVICE_TYPE = “test”

Storage device configuration

MENDER_STORAGE_DEVICE = “/dev/mmcblk2”
MENDER_STORAGE_DEVICE_BASE = “/dev/mmcblk2p”
MENDER_STORAGE_TOTAL_SIZE_MB = “8192”

Partition configuration

MENDER_BOOT_PART = “${MENDER_STORAGE_DEVICE_BASE}1”
MENDER_ROOTFS_PART_A = “${MENDER_STORAGE_DEVICE_BASE}2”
MENDER_ROOTFS_PART_B = “${MENDER_STORAGE_DEVICE_BASE}3”
MENDER_DATA_PART = “${MENDER_STORAGE_DEVICE_BASE}4”

Partition sizes

MENDER_DATA_PART_SIZE_MB = “1024”
MENDER_PARTITION_ALIGNMENT = “1048576”
MENDER_BOOT_PART_SIZE_MB = “64”

U-Boot configuration for Mender

#MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET = “4194304”
#MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET = “7340032”
#MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 = “7602176”
MENDER_UBOOT_AUTO_CONFIGURE = “0”

Kernel and boot settings

MENDER_KERNEL_IMAGETYPE = “Image”
MENDER_BOOT_KERNEL_TYPE = “booti”

Mender features

MENDER_FEATURES_ENABLE:append = " mender-uboot"
MENDER_FEATURES_DISABLE:append = " mender-grub mender-image-uefi"

Server configuration

MENDER_SERVER_URL = “https://docker.mender.io”
MENDER_TENANT_TOKEN = “”
MENDER_UPDATE_POLL_INTERVAL_SECONDS = “1800”
MENDER_ARTIFACT_EXTRA_ARGS = “–no-checksum-provide”

Image configuration

IMAGE_ROOTFS_SIZE = “1769472”
IMAGE_BASENAME = “test-dev”
IMAGE_NAME = “${IMAGE_BASENAME}-${MACHINE}-${DATETIME}”
IMAGE_FEATURES:append = " ssh-server-openssh"

Package installations

IMAGE_INSTALL:append = " 
... 
"
IMAGE_INSTALL:append = " chrony"
IMAGE_INSTALL:append = " mender-machine-id"

U-Boot providers

PREFERRED_PROVIDER_mender-native = “mender-native”
PREFERRED_RPROVIDER_mender-auth = “mender”
PREFERRED_RPROVIDER_mender-update = “mender”

fw_printenv configuration

PREFERRED_PROVIDER_u-boot-fw-utils = “mender-uboot-set-env”
PREFERRED_PROVIDER_virtual/bootloader = “u-boot-imx”

UBOOT_ENV_PART_NAME = “uboot_env”
#UBOOT_ENV_SIZE = “0x20000”
MENDER_UBOOT_ENV_STORAGE_DEVICE = “/dev/mmcblk2boot0”
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 = “4194304”
MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 = “16777216”

IMAGE_INSTALL:append = " kernel-modules"
IMAGE_BOOT_FILES += “Image imx8mm-evk.dtb”
MENDER_IMAGE_BOOT_FILES = “Image imx8mm-evk.dtb”

WKS_FILE = “test.wks.in”

When I try to push an update to my device, using mender-update check-update , it switches to passive partition and here it downloads the artifact. After reboot, device shows the rootfs (“/“) on the partition where the artifact have been installed, which is correct. But the mender server still shows the status for device “rebooting“ even if this has already started and contains the update.

After reboot (The update got installed), the device lost connection to the mender server and the mender server sees the device like a new one that wants to connect, failing to recognize it as the same device that was in the middle of an update deployment and after another reboot the device rolls back to the previous firmware version BUT the new version is still on the other partition. Also, when I use mender-update show-artifact command, it shows “unknown“. These are the logs:
{“timestamp”:“2025-11-17T10:36:06.315874Z”,“level”:“error”,“message”:“Failed to set new authentication data on HTTP request”}
{“timestamp”:“2025-11-17T10:36:06.316212Z”,“level”:“error”,“message”:“Request to push status data failed: Cannot submit API request”}
{“timestamp”:“2025-11-17T10:36:06.316376Z”,“level”:“error”,“message”:“Could not send deployment status: Unauthorized error: Cannot submit API request”}

I checked the /etc/mender/ and /data/mender/ files and nothing changes before and after update, except /data/mender/mender-store file. Although, the date is set correctly and /etc/machine-id is the same on both partitions.

These are some outputs before the update:

#lsblk

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0  7.3G  0 disk
|-mmcblk2p1  179:1    0 83.2M  0 part /uboot
|                                     /boot
|-mmcblk2p2  179:2    0  2.6G  0 part /
|-mmcblk2p3  179:3    0  2.6G  0 part
`-mmcblk2p4  179:4    0    2G  0 part /data
mmcblk2boot0 179:32   0    4M  1 disk
mmcblk2boot1 179:64   0    4M  1 disk

#fw_printenv
baudrate=115200
bootcmd=run mender_setup; run mmcargs; run mmcboot
bootcount=0
bootdelay=2
bootlimit=3
console=ttymxc1,115200
fdt_addr_r=0x43000000
fdt_file=imx8mm-evk.dtb
image=Image
loadaddr=0x40400000
loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdt_file}
loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}
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 ment
mender_boot_part=2
mender_boot_part_hex=2
mender_setup=setenv mender_boot_part_num ${mender_boot_part}; setenv mender_kernel_root /dev/mmcblk2p${mender_boot_part}; setenv mmcroot /dev/mmcblk2p${mendw
mender_uboot_boot=mmc 2:1
mender_uboot_dev=2
mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot} rootwait rw initcall_blacklist=megasas_init
mmcboot=echo Booting from MMC...; run mmcargs; if run loadimage; then if run loadfdt; then booti ${loadaddr} - ${fdt_addr_r}; fi; fi
mmcdev=2
mmcpart=1
mmcroot=/dev/mmcblk2p${mender_boot_part} rootwait rw
upgrade_available=0

These are the outputs after the update:

# lsblk

NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk2      179:0    0  7.3G  0 disk
|-mmcblk2p1  179:1    0 83.2M  0 part /uboot
|-mmcblk2p2  179:2    0  2.6G  0 part
|-mmcblk2p3  179:3    0  2.6G  0 part /
`-mmcblk2p4  179:4    0    2G  0 part /data
mmcblk2boot0 179:32   0    4M  1 disk
mmcblk2boot1 179:64   0    4M  1 disk

#fw_printenv
baudrate=115200
bootcmd=run mender_setup; run mmcargs; run mmcboot
bootcount=0
bootdelay=2
bootlimit=3
console=ttymxc1,115200
fdt_addr_r=0x43000000
fdt_file=imx8mm-evk.dtb
image=Image
loadaddr=0x40400000
loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdt_file}
loadimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}
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 ment
mender_boot_part=3
mender_boot_part_hex=3
mender_setup=setenv mender_boot_part_num ${mender_boot_part}; setenv mender_kernel_root /dev/mmcblk2p${mender_boot_part}; setenv mmcroot /dev/mmcblk2p${mendw
mender_uboot_boot=mmc 2:1
mender_uboot_dev=2
mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot} rootwait rw initcall_blacklist=megasas_init
mmcboot=echo Booting from MMC...; run mmcargs; if run loadimage; then if run loadfdt; then booti ${loadaddr} - ${fdt_addr_r}; fi; fi
mmcdev=2
mmcpart=1
mmcroot=/dev/mmcblk2p${mender_boot_part} rootwait rw
upgrade_available=1

Hi @biancaxyz,

Thanks for reaching out! So to be clear, after the update reboot the device shows up as a new pending device?

In that case it’s a very strong sign that the device identity is changing. By default, Mender uses the first ethernet interface MAC address for this. If for whatever reason this MAC address is being re-created, randomized, whatever upon system update, then the device identity is jeopardized. To fix this, you have to either make sure the MAC address is persistent, or provide an alternative, persistent device identity. See Identity | Mender documentation for more details and examples.

Greetz,
Josef