# Error in U-Boot setup: Boot and Root partitions don't match
**URL:** https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855
**Category:** General Discussions
**Tags:** raspberry-pi-zero-wifi, warrior
**Created:** [July 25, 2019, 9:57pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855 "2019-07-25T21:57:27Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@davidknezic](https://hub.mender.io/u/davidknezic)
#### Post date: [July 25, 2019, 9:57pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/1 "2019-07-25T21:57:28Z")
Dear community,
I recently had to upgrade my entire build to Yocto 2.7 (warrior). I’m aware that Mender doesn’t officially support this latest version yet, but was hopeful that I might still get basic standalone updating working for my first batch of devices after my image built successfuly.
I’m using:
- Yocto 2.7
- [meta-mender@master](https://github.com/mendersoftware/meta-mender/commit/0265e454b1527e17db7a27e8e244c48cbf868f95)
- Mender 2.0.1 (runtime: go1.12.1)
- Raspberry Pi Zero W
- [meta-raspberry@master](https://github.com/agherzan/meta-raspberrypi/commit/6c07f239fa4d136fdbd010272502fbbb30b86ee9)
- Source [meta-candy](https://github.com/the-lightning-land/meta-candy)
When I try to install an update using:
`root@raspberrypi0-wifi:~# mender -install http://192.168.1.121:5000/core-image-base-raspberrypi0-wifi--20190725204233.mender`
The process results in the following error:
> Failed to read the current active partition: No match between boot and root partitions.: Failed mender\_saveenv\_canary check. There is an error in the U-Boot setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment location and the location specified in /etc/fw\_env.config. 2) ‘mender\_setup’ is not run by the U-Boot boot script: exit status 1
> **full output**
>
> ```
> INFO[0000] Loaded configuration file: /var/lib/mender/mender.conf module=config
> INFO[0000] Loaded configuration file: /etc/mender/mender.conf module=config
> ERRO[0000] Failed to read the current active partition: No match between boot and root partitions.: Failed mender_saveenv_canary check. There is an error in the U-Boot setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment location and the location specified in /etc/fw_env.config. 2) 'mender_setup' is not run by the U-Boot boot script: exit status 1 module=main
> INFO[0000] Performing remote update from: [http://192.168.1.121:5000/core-image-base-raspberrypi0-wifi--20190725204233.mender]. module=standalone
> Installing Artifact of size 98060800...
> INFO[0000] no public key was provided for authenticating the artifact module=installer
> INFO[0000] Update Module path "/usr/share/mender/modules/v3" could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available module=modules
> ERRO[0000] Download failed: Payload: can not install Payload: core-image-base-raspberrypi0-wifi.ext4: No match between boot and root partitions.: Failed mender_saveenv_canary check. There is an error in the U-Boot setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment location and the location specified in /etc/fw_env.config. 2) 'mender_setup' is not run by the U-Boot boot script: exit status 1 module=standalone
> ERRO[0000] Payload: can not install Payload: core-image-base-raspberrypi0-wifi.ext4: No match between boot and root partitions.: Failed mender_saveenv_canary check. There is an error in the U-Boot setup. Likely causes are: 1) Mismatch between the U-Boot boot loader environment location and the location specified in /etc/fw_env.config. 2) 'mender_setup' is not run by the U-Boot boot script: exit status 1 module=main
>
> ```
Here’s the contents of the `/etc/fw_env.config` file:
```
/dev/mmcblk0 0x400000 0x4000
/dev/mmcblk0 0x800000 0x4000
```
> **fw\_printenv output**
>
> ```
> altbootcmd=run mender_altbootcmd; run bootcmd
> bootlimit=1
> bootcount=0
> upgrade_available=0
> mender_boot_part=2
> mender_boot_part_hex=2
> mender_uboot_boot=mmc 0:1
> mender_uboot_if=mmc
> mender_uboot_dev=0
> mender_boot_kernel_type=bootm
> mender_kernel_name=uImage
> mender_dtb_name=bcm2710-rpi-cm3.dtb
> mender_pre_setup_commands=
> mender_post_setup_commands=
> mender_check_saveenv_canary=1
> mender_setup=if test "${mender_saveenv_canary}" != "1"; then setenv mender_saveenv_canary 1; saveenv; fi; if test "${mender_pre_setup_commands}" != ""; then run mender_pre_setup_comm
> ands; fi; setenv mender_kernel_root /dev/mmcblk0p${mender_boot_part}; if test ${mender_boot_part} = 2; then setenv mender_boot_part_name /dev/mmcblk0p2; else setenv mender_boot_part_
> name /dev/mmcblk0p3; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_uboot_root mmc 0:${mender_boot_part_hex}; setenv mender_uboot_root_name ${mender_boot_
> part_name}; setenv expand_bootargs "setenv bootargs \\"${bootargs}\\""; run expand_bootargs; setenv expand_bootargs; if test "${mender_post_setup_commands}" != ""; then run mender_po
> st_setup_commands; fi
> 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 mender_boot_part_hex 2; fi; s
> etenv upgrade_available 0; saveenv; run mender_setup
> mender_try_to_recover=if test ${upgrade_available} = 1; then reset; fi
> bootcmd=run distro_bootcmd
> bootdelay=2
> baudrate=115200
> preboot=usb start
> loadaddr=0x00200000
> arch=arm
> cpu=arm1176
> board=rpi
> board_name=rpi
> vendor=raspberrypi
> soc=bcm283x
> dhcpuboot=usb start; dhcp u-boot.uimg; bootm
> stdin=serial,usbkbd
> stdout=serial,vidconsole
> stderr=serial,vidconsole
> fdt_high=ffffffff
> initrd_high=ffffffff
> kernel_addr_r=0x00080000
> scriptaddr=0x02400000
> pxefile_addr_r=0x02500000
> fdt_addr_r=0x02600000
> ramdisk_addr_r=0x02700000
> mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
> boot_net_usb_start=usb start
> usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
> boot_efi_binary=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr ${fdtcontroladdr};fi;load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r}
> efi/boot/bootarm.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
> load_efi_dtb=load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}${efi_fdtfile}
> efi_dtb_prefixes=/ /dtb/ /dtb/current/
> scan_dev_for_efi=setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; then setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; for prefix in ${efi_dtb_prefixes};
> do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${efi_fdtfile}; then run load_efi_dtb; fi;done;if test -e ${devtype} ${devnum}:${distro_bootpart} efi/boot/bootarm.efi
> ; then echo Found EFI removable media binary efi/boot/bootarm.efi; run boot_efi_binary; echo EFI LOAD FAILED: continuing...; fi; setenv efi_fdtfile
> boot_prefixes=/ /boot/
> boot_scripts=boot.scr.uimg boot.scr
> boot_script_dhcp=boot.scr.uimg
> boot_targets=mmc0 mmc1 usb0 pxe dhcp
> boot_syslinux_conf=extlinux/extlinux.conf
> boot_extlinux=sysboot ${devtype} ${devnum}:${distro_bootpart} any ${scriptaddr} ${prefix}${boot_syslinux_conf}
> scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${boot_syslinux_conf}; then echo Found ${prefix}${boot_syslinux_conf}; run boot_extlinux; echo SCRIP
> T FAILED: continuing...; fi
> boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
> scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run bo
> ot_a_script; echo SCRIPT FAILED: continuing...; fi; done
> scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done;run scan_dev_
> for_efi;
> scan_dev_for_boot_part=part list ${devtype} ${devnum} -bootable devplist; env exists devplist || setenv devplist 1; for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devn
> um}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
> bootcmd_mmc0=setenv devnum 0; run mmc_boot
> bootcmd_mmc1=setenv devnum 1; run mmc_boot
> bootcmd_usb0=setenv devnum 0; run usb_boot
> bootcmd_pxe=run boot_net_usb_start; dhcp; if pxe get; then pxe boot; fi
> bootcmd_dhcp=run boot_net_usb_start; if dhcp ${scriptaddr} ${boot_script_dhcp}; then source ${scriptaddr}; fi;setenv efi_fdtfile ${fdtfile}; if test -z "${fdtfile}" -a -n "${soc}"; t
> hen setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; fi; setenv efi_old_vci ${bootp_vci};setenv efi_old_arch ${bootp_arch};setenv bootp_vci PXEClient:Arch:00010:UNDI:003000;setenv
> bootp_arch 0xa;if dhcp ${kernel_addr_r}; then tftpboot ${fdt_addr_r} dtb/${efi_fdtfile};if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r}; else bootefi ${kernel_
> addr_r} ${fdtcontroladdr};fi;fi;setenv bootp_vci ${efi_old_vci};setenv bootp_arch ${efi_old_arch};setenv efi_fdtfile;setenv efi_old_arch;setenv efi_old_vci;
> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
>
> ```
I configure `meta-mender` as follows:
```
#
# Mender
#
# These are all provided by the meta-mender-core and meta-mender-raspberry layers
#
MENDER_FEATURES_ENABLE += "\
mender-uboot \
mender-image \
mender-image-sd \
mender-install \
"
# Memory card storage
MENDER_STORAGE_DEVICE = "/dev/mmcblk0"
# Memory card labeled 8GiB
MENDER_STORAGE_TOTAL_SIZE_MB = "7555"
# These are simply to align with how the "stock" RPi machines are
# configured.
MENDER_PARTITION_ALIGNMENT = "4194304"
MENDER_BOOT_PART_SIZE_MB = "40"
MENDER_DATA_PART_SIZE_MB = "512"
# rpi-base.inc removes these as they are normally installed on to the
# vfat boot partition. To be able to update the Linux kernel Mender
# uses an image that resides on the root file system and below line
# ensures that they are installed to /boot
IMAGE_INSTALL_append += "kernel-image kernel-devicetree"
# The artifact name is the Bitcoin block number at the point of the build
# https://blockstream.info/block/00000000000000000013680dae0234163c1b7af585990e694b621381d02b47da
MENDER_ARTIFACT_NAME = "582010"
# Mender will build an image called `sdimg` which shall be used instead
# of `rpi-sdimg`.
IMAGE_FSTYPES_remove += "rpi-sdimg"
# Use the same type here as specified in ARTIFACTIMG_FSTYPE to avoid
# building an unneeded image file.
SDIMG_ROOTFS_TYPE = "ext4"
ARTIFACTIMG_FSTYPE = "ext4"
```
And set `RPI_USE_U_BOOT = "1"`.
The full configuration can be found in [meta-candy/conf/distro/candy.conf](https://github.com/the-lightning-land/meta-candy/blob/warrior/conf/distro/candy.conf).
I’ve tried to figure out where exactly the cause for this problem is, but failed in finding out. Now I don’t know if I should pursue this path further or revert to _thud_ and try to resolve the other unrelated issues that made me upgrade in the first place.
I’d greatly appreciate any hints on how this could be resolved and feedback if there’s an easy fix at all. Thank you! 🙌
David
---
### Author:  [@drewmoseley](https://hub.mender.io/u/drewmoseley)
#### Post date: [July 26, 2019, 3:33pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/2 "2019-07-26T15:33:19Z")
Hi David,
Welcome to Mender Hub. We definitely appreciate hearing from users.
It seems that the environment is mismatched between UBoot and Linux. On my current RpI3 build, from thud, the fw\_env.config file is identical to yours so the issue is something else.
I suggest you start by dumping the environment from UBoot and from Linux and comparing them.
---
### Author:  [@davidknezic](https://hub.mender.io/u/davidknezic)
#### Post date: [July 26, 2019, 8:09pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/3 "2019-07-26T20:09:25Z")
Hi Drew, thank you!
Here is the diff between the uboot and linux variables: [davidknezic/linux.txt](https://gist.github.com/davidknezic/086824ff6ecab1e011ed3d14864a6160/revisions#diff-3c94bf339ba3deec6ecf25985fa53ea1).
I made some more tests and experiments trying to narrow down the problem. I’ve learnt from [Mender’s source code](https://github.com/mendersoftware/meta-mender/pull/550) that it queries a specific variable during the check that fails for me:
```
root@raspberrypi0-wifi:~# fw_printenv mender_saveenv_canary
Warning: Bad CRC, using default environment
## Error: "mender_saveenv_canary" not defined
```
Interestingly, running that command returns an odd CRC error and reports that the value is missing, which can also be seen in the diff above.
I then tried to set the variable manually, to see if the updating process would work. After setting the variable, the CRC error disappeared and I ran an update.
```
root@raspberrypi0-wifi:~# mender -data /data/mender/ -config /data/mender/mender.conf -install http://192.168.1.121:5000/core-image-base-raspberrypi0-wifi--20190726162603.mender
INFO[0000] Loaded configuration file: /var/lib/mender/mender.conf module=config
INFO[0000] Loaded configuration file: /data/mender/mender.conf module=config
WARN[0000] No server URL(s) specified in mender configuration. module=config
WARN[0000] Server entry 1 has no associated server URL. module=config
INFO[0000] Mender running on partition: /dev/mmcblk0p2 module=main
INFO[0000] Performing remote update from: [http://192.168.1.121:5000/core-image-base-raspberrypi0-wifi--20190726162603.mender]. module=standalone
Installing Artifact of size 99718144...
INFO[0000] no public key was provided for authenticating the artifact module=installer
INFO[0000] Update Module path "/usr/share/mender/modules/v3" could not be opened (open /usr/share/mender/modules/v3: no such file or directory). Update modules will not be available module=modules
INFO[0000] native sector size of block device /dev/mmcblk0p3 is 512, we will write in chunks of 1048576 module=dual_rootfs_device
INFO[0000] opening device /dev/mmcblk0p3 for writing module=block_device
INFO[0000] partition /dev/mmcblk0p3 size: 3661627392 module=block_device
................................ 1% 1024 KiB
................................ 2% 2048 KiB
(21 minutes later)
...INFO[1254] wrote 3661627392/3661627392 bytes of update to device /dev/mmcblk0p3 module=dual_rootfs_device
100% 97381 KiB
INFO[1255] Enabling partition with new image installed to be a boot candidate: 3 module=dual_rootfs_device
Use -commit to update, or -rollback to roll back the update.
At least one payload requested a reboot of the device it updated.
```
It seemed to work.
```
root@raspberrypi0-wifi:~# fw_printenv mender_boot_part
mender_boot_part=3
root@raspberrypi0-wifi:~# fw_printenv bootcount
bootcount=0
root@raspberrypi0-wifi:~# cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 cma=256M smsc95xx.macaddr=B8:27:EB:14:4F:98 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 rootfstype=ext4 rootwait logo.nologo root=/dev/mmcblk0p2
```
`reboot`
However, after a reboot the device booted from the previous partition `/dev/mmcblk0p2` again.
```
root@raspberrypi0-wifi:~# cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 cma=256M smsc95xx.macaddr=B8:27:EB:14:4F:98 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 rootfstype=ext4 rootwait logo.nologo root=/dev/mmcblk0p2
```
I rebooted and entered the uboot console after that to look into the environment. It still references the old partition `mender_boot_part=2`. So I thought let’s intervene manually again and see if I could even boot from the updated partition:
```
U-Boot> setenv mender_boot_part 3
U-Boot> setenv mender_boot_part_hex 3
U-Boot> run mender_setup
U-Boot> run bootcmd
```
With that manual intervention it boots from the correct partition `/dev/mmcblk0p3`.
```
root@raspberrypi0-wifi:~# cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 cma=256M smsc95xx.macaddr=B8:27:EB:14:4F:98 vc_mem.mem_base=0x1fa00000 vc_mem.mem_size=0x20000000 dwc_otg.lpm_enable=0 console=ttyS0,115200 rootfstype=ext4 rootwait logo.nologo root=/dev/mmcblk0p3
```
So it seems that the uboot and linux environments really aren’t in sync which causes all the trouble. Do you have an idea how I could try to fix this?
---
### Author:  [@drewmoseley](https://hub.mender.io/u/drewmoseley)
#### Post date: [July 26, 2019, 9:01pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/4 "2019-07-26T21:01:56Z")
Hi David,
The CRC error is normal when the environment block has not been initialized. Basically, UBoot has a default setup of environment variables that will be used in this case.
I just took a look in the thud branch and that indicates that auto-configure doesn’t work for RpI due to it’s use of a boot script instead of the standard Mender environment additions. [https://github.com/mendersoftware/meta-mender/blob/352cd81fe4dd6e44ba0819da1d8e189109e805e6/meta-mender-raspberrypi/recipes-bsp/u-boot/u-boot-raspberrypi.inc#L5](https://github.com/mendersoftware/meta-mender/blob/352cd81fe4dd6e44ba0819da1d8e189109e805e6/meta-mender-raspberrypi/recipes-bsp/u-boot/u-boot-raspberrypi.inc#L5)
I think you need to disable auto-configuration and see if you can get it to build.
Drew
---
### Author:  [@davidknezic](https://hub.mender.io/u/davidknezic)
#### Post date: [July 27, 2019, 12:58pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/5 "2019-07-27T12:58:23Z")
Hi Drew,
Okay. It already seems like auto-configure is disabled:
```
bitbake -e u-boot | grep '^MENDER_UBOOT_AUTO_CONFIGURE='
MENDER_UBOOT_AUTO_CONFIGURE="0"
```
Interestingly through, I’d assume that `0001-CONFIGS-rpi-enable-mender-requirements.patch` shouldn’t be applied then, but I just discovered this in the logs:
> Applying patch 0001-CONFIGS-rpi-enable-mender-requirements.patch
> patching file configs/rpi\_0\_w\_defconfig
> Hunk #1 succeeded at 38 (offset 13 lines).
> patching file configs/rpi\_2\_defconfig
> Hunk #1 succeeded at 38 (offset 6 lines).
> patching file configs/rpi\_3\_32b\_defconfig
> Hunk #1 succeeded at 41 (offset 7 lines).
> patching file configs/rpi\_3\_defconfig
> Hunk #1 succeeded at 41 (offset 7 lines).
> patching file configs/rpi\_defconfig
> Hunk #1 succeeded at 38 (offset 6 lines).
> patching file include/configs/rpi.h
> Hunk #1 succeeded at 75 with fuzz 2 (offset -16 lines).
> The context lines in the patches can be updated with devtool:
> devtool modify u-boot
> devtool finish --force-patch-refresh u-boot \
> Don’t forget to review changes done by devtool!
> WARNING: u-boot-1\_2019.01-r0 do\_patch: QA Issue: Patch log indicates that patches do not apply cleanly. [patch-fuzz]
> WARNING: u-boot-1\_2019.01-r0 do\_provide\_mender\_defines: Found more than one dtb specified in KERNEL\_DEVICETREE. Only one should be specified. Choosing the last one.
So I added an `u-boot_%.bbappend` file with `MENDER_UBOOT_AUTO_CONFIGURE = "0"` in it and I assume that now auto-configure is disabled. At least [some variables are gone](https://gist.github.com/davidknezic/086824ff6ecab1e011ed3d14864a6160/revisions#diff-0abe1f5280ee8953c131e30a4be27a65) from the u-boot environment.
The error still persists. Does that now mean I need to do the patching myself according to this guide?
[https://docs.mender.io/2.0/devices/yocto-project/bootloader-support/u-boot/manual-u-boot-integration#u-boot-features](https://docs.mender.io/2.0/devices/yocto-project/bootloader-support/u-boot/manual-u-boot-integration#u-boot-features)
---
### Author:  [@davidknezic](https://hub.mender.io/u/davidknezic)
#### Post date: [July 29, 2019, 1:01am UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/6 "2019-07-29T01:01:30Z")
Oh well, it seems I misunderstood the meta-mender-raspberry u-boot append. The patch of course is supposed to be applied when `MENDER_UBOOT_AUTO_CONFIGURE = "0"`. There is slight fuzz according to the logs, but the patched files look correct, the configs and the include file.
I notice that this CRC warning always comes up, when in user space. Even after several restarts and manual uboot saveenv. I wonder if it is possible that the fw\_env.config doesn’t point to the correct env address. I can see the `mender_saveenv_canary` variable set to `1` in the uboot shell after the first boot, but never see it in user space because it always pulls the default env.
Is it possible that this is the issue and if so, is there a way to find out where the env is saved exactly?
---
### Author:  [@drewmoseley](https://hub.mender.io/u/drewmoseley)
#### Post date: [July 29, 2019, 3:56pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/7 "2019-07-29T15:56:15Z")
I suppose that is likely the case but it’s odd that the version in Thud has the same fw\_env.config without exhibiting this issue.
I would look at regenerating the patches in question so they apply cleanly; there are some cases where that doesn’t work properly.
As for finding the environment location, the only way I know to do it is to dig through the configured UBoot sources.
Drew
---
### Author:  [@mirzak](https://hub.mender.io/u/mirzak)
#### Post date: [July 31, 2019, 2:28pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/8 "2019-07-31T14:28:43Z")
You can check the U-boot configuration in Yocto with the following:
```auto
cat tmp/work/raspberrypi3-poky-linux-gnueabi/u-boot/1_2019.01-r0/git/include/config_mender_defines.h
```
Note that you might need to run:
```auto
bitbake -c cleansstate u-boot
bitbake -c deploy u-boot
```
For the file to appear (it might get cleaned up by Yocto).
I did a quick test run, trying to reproduce your environment and the variables do turn out correct to me (matching what is in `/etc/fw_env.config`),
```auto
/* Shell variables */
#define MENDER_BOOT_PART_NUMBER 1
#define MENDER_BOOT_PART_NUMBER_HEX 1
#define MENDER_ROOTFS_PART_A_NUMBER 2
#define MENDER_ROOTFS_PART_A_NUMBER_HEX 2
#define MENDER_ROOTFS_PART_B_NUMBER 3
#define MENDER_ROOTFS_PART_B_NUMBER_HEX 3
#define MENDER_UBOOT_STORAGE_INTERFACE "mmc"
#define MENDER_UBOOT_STORAGE_DEVICE 0
/* BB variables. */
#define MENDER_STORAGE_DEVICE "/dev/mmcblk0"
#define MENDER_STORAGE_DEVICE_BASE "/dev/mmcblk0p"
#define MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_1 0x400000
#define MENDER_UBOOT_ENV_STORAGE_DEVICE_OFFSET_2 0x800000
#define MENDER_ROOTFS_PART_A_NAME "/dev/mmcblk0p2"
#define MENDER_ROOTFS_PART_B_NAME "/dev/mmcblk0p3"
/* For sanity checks. */
#define MENDER_BOOTENV_SIZE 0x4000
```
Currently on the road though so not able to test anything.
---
### Author:  [@mirzak](https://hub.mender.io/u/mirzak)
#### Post date: [August 6, 2019, 2:38pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/9 "2019-08-06T14:38:47Z")
Had a chance to test things out on warrior, and I have something working here for Raspberry Pi,
> **[mirzak/meta-mender](https://github.com/mirzak/meta-mender/tree/warrior-raspberrypi)**
>
> Yocto meta layer. Contribute to mirzak/meta-mender development by creating an account on GitHub.
Will be merged in the official meta-mender once official warrior support is added.
---
### Author:  [@davidknezic](https://hub.mender.io/u/davidknezic)
#### Post date: [August 7, 2019, 3:30pm UTC](https://hub.mender.io/t/error-in-u-boot-setup-boot-and-root-partitions-dont-match/855/10 "2019-08-07T15:30:55Z")
Mirza, thank you! Your rebased uboot patch made it work on warrior. I was able to successfully update my candy dispenser firmware. 😋
The changes even work with the master branches of poky, oe and the raspberrypi layer, with a slight modification of the e2fsprogs csum patch: [https://github.com/the-lightning-land/meta-mender/commit/7d626ac04cb84ecd891448f3678533a5c281ed9c](https://github.com/the-lightning-land/meta-mender/commit/7d626ac04cb84ecd891448f3678533a5c281ed9c)