Mender with Yocto, RPI3 and No match between root & boot partitions

I’m now trying to set up mender and make use of the features. I’m experiencing an error that seems to have occurred for other people.

To summarise, I created a set up in Yocto which is similar to the script Drew Moseley created here.

The main differences are:

  1. I’m using Dunfell instead of Rocko
  2. I have added an extra layer which is a copy of the stargazer recipe here to add recipes for systemd as a service and additional networking.
  3. I’ve modified local.conf as to be as shown below. The key points are the use of U-boot.

IMAGE_FEATURES_remove += “splash”
MENDER_STORAGE_DEVICE = “/dev/mmcblk0”
INHERIT += “mender-full”
MACHINE = “raspberrypi3”
IMAGE_INSTALL_append = " kernel-image kernel-devicetree"
IMAGE_FSTYPES_remove += " rpi-sdimg"
IMAGE_BOOT_FILES_append = " boot.scr u-boot.bin;${SDIMG_KERNELIMAGE}"
INHERIT += “rpi-update-firmware”
DISTRO_FEATURES_append = " systemd"
VIRTUAL-RUNTIME_init_manager = “systemd”
VIRTUAL-RUNTIME_initscripts = “”

When I run bitbake core-image-full-cmdline, the build configuration output is:

Build Configuration:
BB_VERSION = “1.46.0”
BUILD_SYS = “x86_64-linux”
TARGET_SYS = “arm-poky-linux-gnueabi”
MACHINE = “raspberrypi3”
DISTRO = “poky”
TUNE_FEATURES = “arm vfp cortexa7 neon vfpv4 thumb callconvention-hard”
TARGET_FPU = “hard”
meta-yocto-bsp = “dunfell:e79ccaa277d8a67429e5b5693236e2c98e395f24”
meta-networking = “dunfell:f2d02cb71eaff8eb285a1997b30be52486c160ae”
meta-raspberrypi = “dunfell:987993209716302eb8f314f69a2a3340555f94d8”
meta-mender-raspberrypi = “dunfell:cc1fdd90820bf8912007b399217bdc3278473165”
meta-stargazer = “:”

I flashed an SD card using the command

sudo dd if=core-image-full-cmdline-raspberrypi3.sdimg of=/dev/sdb bs=4M

I then booted the RPI3 and logged in. When I run the command

mender show-artifact

I get

ERRO[0000] Failed to read the current active partition: No match between boot and root partitions. : exit status 243.

If I type cat /etc/fw_env.config the output is:

/dev/mmcblk0 0x400000 0x4000
/dev/mmcblk0 0x800000 0x4000

From my understanding this looks correct. However, I suspect the problem because of a mismatch between U-Boot and the kernel. To investigate, I’ve gone into U-boot and typed printenv but I’m not sure which variables I should check.

I’m not completely wedded to using U-Boot. If there’s a simpler solution without it then I’d be happy to follow a recommendation either way.

My goal is to have an operational system where I can more recipes for a Qt touchscreen application and make use of mender updates.

1 Like

I did further troubleshooting with fw_printenv mender_boot_part and I get the same error described here in the issue MEN-3834

I’m not sure if I should update the conf/local.conf settings.

I decided to swap to the earlier Yocto version Zeus. It wouldn’t build with these two lines in my local.conf

IMAGE_BOOT_FILES_append = " boot.scr u-boot.bin;${SDIMG_KERNELIMAGE}"
INHERIT += “rpi-update-firmware”

I removed those since it’s not essential for me now. I don’t have the same problems now.

FYI. I did a git pull on the dunfell branch of meta-mender last week after originally posting my question. I noticed there were some changes. I still had the problem with dunfell after this. I’ll investigate further.

Hello @simonboland

I experience the same issue right now, I’m using dunfell (commit f5864bfb32906b87cc24d5b84e74805994f0ef3e 25th of January 2021) and I have quite the same configuration.

Have you found a solution ? Or are yu stil on Zeus ? Seems the issue you reference above (MEN-3834) do not help here.

Dunfell is LTS so my preference at this time. If any body has a similar issue (just notice also Mender integration of STM32MP157C on dunfell - #2 by mirzak which is very similar, maybe identical issue).


1 Like

I couldn’t find a solution. I simply switched to Zeus. It worked for me. I can supply the local.conf if that helps.

Thanks for the quick answer. Tried a little bit but not enough familiar with mender yet, so I switched to Zeus too.

Confirmed Zeus working and Dunfell doesn’t.


Hi @joelguittet @simonboland I just ran a fresh build from the current HEAD of dunfell and could not reproduce this. Can you confirm what git hashes you are using on dunfell that exhibits the issue?

I may not be able to try it again soon but I’ll let you know if I do.

Hello @drewmoseley

f5864bfb32906b87cc24d5b84e74805994f0ef3e confirmed not working for me. RPi CM3 device.


@joelguittet any chance you can check on a standard RpI3? I don’t have a CM3 to check with. I doubt it would be specific to the hardware but it’s possible.

@lluiscampos do you have any ideas here?

@drewmoseley I have only CM3 available, sorry.
I have seen plenty of differences on meta-mender between zeus and dunfell, particularly at u-boot level. Is it normal ?


Yes, differences between the branches are expected.

After upgrading from thud to dunfell, I am also experiencing the same problems. I am running on a Raspberry pi 3b+.

1 Like

@jostor I’ve not been able to reproduce this. Can you provide your sdimg file so I can try that directly? If you have Google Drive or Dropbox or some such you can probably share it directly with me there.

@drewmoseley Thanks for your reply! I think I solved it.

I saw that I got this warning when bitbaking u-boot:

WARNING: u-boot-1_2020.01-r0 do_provide_mender_defines: Found more than one dtb specified in KERNEL_DEVICETREE ( bcm2708-rpi-zero-w.dtb bcm2708-rpi-b.dtb bcm2708-rpi-b-plus.dtb bcm2709-rpi-2-b.dtb bcm2710-rpi-3-b.dtb bcm2710-rpi-3-b-plus.dtb bcm2711-rpi-4-b.dtb bcm2708-rpi-cm.dtb bcm2710-rpi-cm3.dtb overlays/at86rf233.dtbo overlays/disable-bt.dtbo overlays/dwc2.dtbo overlays/gpio-key.dtbo overlays/hifiberry-amp.dtbo overlays/hifiberry-dac.dtbo overlays/hifiberry-dacplus.dtbo overlays/hifiberry-digi.dtbo overlays/i2c-rtc.dtbo overlays/iqaudio-dac.dtbo overlays/iqaudio-dacplus.dtbo overlays/miniuart-bt.dtbo overlays/mcp2515-can0.dtbo overlays/mcp2515-can1.dtbo overlays/pitft22.dtbo overlays/pitft28-resistive.dtbo overlays/pitft28-capacitive.dtbo overlays/pitft35-resistive.dtbo overlays/pps-gpio.dtbo overlays/rpi-ft5406.dtbo overlays/rpi-poe.dtbo overlays/vc4-kms-v3d.dtbo overlays/vc4-fkms-v3d.dtbo overlays/w1-gpio-pullup.dtbo overlays/w1-gpio.dtbo overlays/gpio-ir.dtbo overlays/gpio-ir-tx.dtbo ). Only one should be specified. Choosing the last one: bcm2710-rpi-cm3.dtb. Set KERNEL_DEVICETREE to the desired dtb file to silence this warning.

I tried adding KERNEL_DEVICETREE = “bcm2710-rpi-3-b-plus.dtb” to my local.conf. It looks like this fixed it. @joelguittet and @simonboland Maybe this will help you too?

I have kept the default config and was not specifying a single device tree.
@drewmoseley and you ? You were not able to reproduce the issue, do you specify a single dtb ?


No, I just leave that at the default.

I realized that the “solution” with adding "KERNEL_DEVICETREE = “bcm2710-rpi-3-b-plus.dtb” probably wasn’t ideal. I lost my overlays, and I guess it was not the correct way to solve this.

I tried setting up a new project following this guide: Raspberry Pi 3 Model B/B+
The image I built this way worked, and I didn’t get these problems. I tried removing all my layers from my original project, but still got the " No match between boot and root partitions" and the “fw_printenv” problems. I compared which git commit was currently checked out on the different layers and checked out the same versions on my originally project. That helped. I think the eroors disappeared after changing the git commit of poky and rebuilding the image.

Originally I cloned the poky project with: git clone git:// --branch yocto-3.1.5 --single-branch
Now, when it is working, poky is on 9ee329c18fbe0c42eaf3d43657ea30591f79143b

1 Like