# Yocto:Dunfell:SAMA5D3: Mender artifact download fails
**URL:** https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425
**Category:** General Discussions
**Created:** [September 10, 2020, 3:28pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425 "2020-09-10T15:28:21Z")
**Posts on this page:** 14
**Page:** 1
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 10, 2020, 3:28pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/1 "2020-09-10T15:28:21Z")
Hi,
I have integrated mender into the Yocto project for the SAMA5D3. The project is based on dunfell. I am using u-boot from mender. Yocto project is creating ubimg with the following volumes:
```
[rootfsA]
mode=ubi
image=(I have removed this line )
vol_id=0
vol_size=103168KiB
vol_type=dynamic
vol_name=rootfsa
[rootfsB]
mode=ubi
image=(I have removed this line )
vol_id=1
vol_size=103168KiB
vol_type=dynamic
vol_name=rootfsb
[data]
mode=ubi
image=(I have removed this line )
vol_id=2
vol_size=16MiB
vol_type=dynamic
vol_name=data
[u-boot-env-1]
mode=ubi
image=(I have removed this line )
vol_id=3
vol_size=4063232
vol_type=dynamic
vol_name=u-boot-env-1
[u-boot-env-2]
mode=ubi
image=(I have removed this line )
vol_id=4
vol_size=4063232
vol_type=dynamic
vol_name=u-boot-env-2
```
I see that all the volumes are present in /dev:
```
root@sama5d3-xplained:~# ls -l /dev/ubi*
crw------- 1 root root 246, 0 Jan 1 2007 /dev/ubi0
crw------- 1 root root 246, 1 Jan 1 2007 /dev/ubi0_0
crw------- 1 root root 246, 2 Jan 1 2007 /dev/ubi0_1
crw------- 1 root root 246, 3 Jan 1 2007 /dev/ubi0_2
crw------- 1 root root 246, 4 Jan 1 2007 /dev/ubi0_3
crw------- 1 root root 246, 5 Jan 1 2007 /dev/ubi0_4
crw------- 1 root root 10, 62 Jan 1 2007 /dev/ubi_ctrl
```
However I see that only ubi0\_0 and ubi0\_2 are mounted:
```
root@sama5d3-xplained:~# mount
ubi0_0 on / type ubifs (rw,relatime,assert=read-only,ubi=0,vol=0)
devtmpfs on /dev type devtmpfs (rw,relatime,size=116160k,nr_inodes=29040,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=666)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /var/volatile type tmpfs (rw,relatime)
ubi0_2 on /data type ubifs (rw,relatime,assert=read-only,ubi=0,vol=2)
tmpfs on /run/user/0 type tmpfs (rw,nosuid,nodev,relatime,size=24972k,mode=700)
```
The issue with this setup is that the mender artifact (I am also building it using the Yocto project) is failing when it tries to update the uboot env volumes (ubi0\_3 and ubi0\_4) since they are not available. I needed to ask if this is an expected behaviour? More confusing to me is why aren’t these volumes mounted by default if the mender artifact updation process needs to write into these volumes.
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [September 11, 2020, 5:32am UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/2 "2020-09-11T05:32:51Z")
It is expected that only ubi0\_0 and ubi0\_2 are mounted. ubi0\_3 and ubi0\_4 are only used as pure block devices where the U-Boot environment is stored. If there are failures when writing to it, the most common cause is that `/etc/fw_env.config` is set up incorrectly. It should contain those volumes.
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 11, 2020, 7:30am UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/3 "2020-09-11T07:30:48Z")
hi kacf, thanks for the reply. I am suspecting the same. But I am not sure what is the issue. Here’s the content of the fw\_config:
```
root@sama5d3-xplained:~# cat /etc/fw_env.config
/dev/ubi0_3 0 0x20000 126976
/dev/ubi0_4 0 0x20000 126976
```
fw\_setenv also fails:
```
root@sama5d3-xplained:~# fw_setenv r 1
Cannot read environment, using default
Cannot read default environment from file
```
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [September 11, 2020, 1:13pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/4 "2020-09-11T13:13:00Z")
It’s possible that U-Boot is set up incorrectly. Can you stop at the U-Boot prompt, and execute:
```auto
printenv mender_saveenv_canary
```
The output should be:
```auto
mender_saveenv_canary=1
```
Note that the related variable `mender_check_saveenv_canary` is not the same thing.
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 11, 2020, 1:19pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/5 "2020-09-11T13:19:50Z")
Yup. I get the expected output:
```
=> printenv mender_saveenv_canary
mender_saveenv_canary=1
=>
```
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 11, 2020, 1:41pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/6 "2020-09-11T13:41:33Z")
I am putting the complete environment from u-boot(printenv):
```
=>
=>
=> printenv
altbootcmd=run mender_altbootcmd; run bootcmd
arch=arm
baudrate=115200
board=sama5d3_xplained
board_name=sama5d3_xplained
bootargs=console=ttyS0,115200 earlyprintk mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env_redundant),256k(env),512k(dtb),6m(kernel)ro,-(ubi) rootfstype=ubifs ubi.mtd=${mender_mtd_ubi_dev_name} root=${mender_kernel_root} rw
bootcmd=run mender_setup;ubi part ${mender_mtd_ubi_dev_name} && ubifsmount ${mender_uboot_root_name} && ubifsload 0x22000000 /boot/zImage && ubifsload 0x21000000 /boot/at91-sama5d3_xplained.dtb && bootz 0x22000000 - 0x21000000
bootcount=1
bootdelay=3
bootlimit=1
cpu=armv7
eth1addr=22:65:46:29:4b:cb
ethact=gmac0
ethaddr=24:56:44:22:5b:ab
fdtcontroladdr=2fb2db68
mender_altbootcmd=if test ${mender_boot_part} = 0; then setenv mender_boot_part 1; setenv mender_boot_part_hex 1; else setenv mender_boot_part 0; setenv mender_boot_part_hex 0; fi; setenv upgrade_available 0; saveenv; run mender_setup
mender_boot_kernel_type=bootz
mender_boot_part=0
mender_boot_part_hex=0
mender_check_saveenv_canary=1
mender_dtb_name=at91-sama5d3_xplained.dtb
mender_kernel_name=zImage
mender_mtd_ubi_dev_name=ubi
mender_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_commands; fi; if test "${mender_systemd_machine_id}" != ""; then setenv bootargs systemd.machine_id=${mender_systemd_machine_id} ${bootargs}; fi; setenv mender_kernel_root ubi0_${mender_boot_part}; if test ${mender_boot_part} = 0; then setenv mender_boot_part_name ubi0:rootfsa; else setenv mender_boot_part_name ubi0:rootfsb; fi; setenv mender_kernel_root_name ${mender_boot_part_name}; setenv mender_uboot_root dummy dummy:${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_post_setup_commands; fi
mender_try_to_recover=if test ${upgrade_available} = 1; then reset; fi
mender_uboot_boot=dummy dummy:
mender_uboot_dev=dummy
mender_uboot_if=dummy
soc=at91
stderr=serial@ffffee00
stdin=serial@ffffee00
stdout=serial@ffffee00
upgrade_available=0
vendor=atmel
Environment size: 2312/131067 bytes
=>
```
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [September 11, 2020, 1:44pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/7 "2020-09-11T13:44:03Z")
Ok, then this is becoming a bit trickier. A couple of questions:
1. Have you changed the value of `MENDER_UBOOT_AUTO_CONFIGURE`?
2. Can you execute the following:
```auto
bitbake -c configure u-boot
bitbake -c devshell u-boot
```
And in the new shell that appears, execute:
```auto
grep ENV_IS_ .config
```
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 11, 2020, 1:49pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/8 "2020-09-11T13:49:56Z")
Here you go:
```
root@ravi-u18:~/yocto-mender-sama5d3-xplained/build/tmp/work/sama5d3_xplained_sd-poky-linux-gnueabi/u-boot-at91/v2020.01-at91+gitAUTOINC+0e1d1b6efb-r0/git# grep ENV_IS_ .config
# CONFIG_ENV_IS_NOWHERE is not set
# CONFIG_ENV_IS_IN_EEPROM is not set
# CONFIG_ENV_IS_IN_FAT is not set
# CONFIG_ENV_IS_IN_EXT4 is not set
# CONFIG_ENV_IS_IN_FLASH is not set
CONFIG_ENV_IS_IN_MMC=y
# CONFIG_ENV_IS_IN_NAND is not set
# CONFIG_ENV_IS_IN_NVRAM is not set
# CONFIG_ENV_IS_IN_ONENAND is not set
# CONFIG_ENV_IS_IN_REMOTE is not set
# CONFIG_ENV_IS_IN_UBI is not set
```
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 11, 2020, 1:58pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/9 "2020-09-11T13:58:04Z")
I forgot to add that I have not changed the value of MENDER\_UBOOT\_AUTO\_CONFIGURE. It remains same defined in u-boot-mender.inc
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 11, 2020, 1:58pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/10 "2020-09-11T13:58:57Z")
Is this the problem?
`CONFIG_ENV_IS_IN_MMC=y`
Shouldn’t it be:
`CONFIG_ENV_IS_IN_NAND`
or
`CONFIG_ENV_IS_IN_UBI`
---
### Author:  [@kacf](https://hub.mender.io/u/kacf)
#### Post date: [September 14, 2020, 6:22am UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/11 "2020-09-14T06:22:48Z")
Yes, it should be `CONFIG_ENV_IS_IN_UBI`. Are you sure you are using `inherit mender-full-ubi` in your `local.conf`, and not `inherit mender-full`?
Other than that, you could try manually improving the patch by following the [manual integration guide](https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot/manual-u-boot-integration#how-to-integrate-with-u-boot). The guide doesn’t explain the UBI support explicitly, so you’ll have to apply some common sense, but probably the automatically generated patch should already be quite close to the desired patch.
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 14, 2020, 6:41am UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/12 "2020-09-14T06:41:18Z")
hey kacf, good mornig. Unfortunately, this is also right ☹
```
# Mender settings
INHERIT += "mender-full-ubi"
```
---
### Author:  [@ravipathak1](https://hub.mender.io/u/ravipathak1)
#### Post date: [September 15, 2020, 4:32pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/13 "2020-09-15T16:32:19Z")
I created a patch by removing(in sama5d3\_xplained\_nandflash\_defconfig, branch u-boot-2020.01-at91):
`#CONFIG_ENV_IS_IN_NAND=y`
and adding:
`CONFIG_ENV_IS_IN_UBI=y`
This presented with the following error:
```
WARNING: u-boot-at91-v2020.01-at91+gitAUTOINC+0e1d1b6efb-r0 do_patch: Fuzz detected:
Applying patch 0001-add_config_env_is_in_ubi.patch
patching file configs/sama5d3_xplained_nandflash_defconfig
Hunk #1 succeeded at 51 with fuzz 2 (offset 6 lines).
The context lines in the patches can be updated with devtool:
devtool modify u-boot-at91
devtool finish --force-patch-refresh u-boot-at91
Don't forget to review changes done by devtool!
WARNING: u-boot-at91-v2020.01-at91+gitAUTOINC+0e1d1b6efb-r0 do_patch: QA Issue: Patch log indicates that patches do not apply cleanly. [patch-fuzz]
ERROR: u-boot-at91-v2020.01-at91+gitAUTOINC+0e1d1b6efb-r0 do_configure: U-Boot configuration sama5d3_xplained_nandflash_config has setting:
CONFIG_ENV_UBI_PART=""
but Mender expects:
CONFIG_ENV_UBI_PART="ubi"
Please fix U-Boot's configuration file.
```
I created a patch again by including in the same defconfig:
```
CONFIG_ENV_UBI_PART="UBI"
```
ANd now it gives following error:
```
Initialising tasks: 100% |###############################################| Time: 0:00:01
Sstate summary: Wanted 31 Found 0 Missed 31 Current 1360 (0% match, 97% complete)
NOTE: Executing Tasks
ERROR: u-boot-at91-v2020.01-at91+gitAUTOINC+0e1d1b6efb-r0 do_patch: Command Error: 'quilt --quiltrc /home/ravi/yocto-mender-sama5d3-xplained/build/tmp/work/sama5d3_xplained-poky-linux-gnueabi/u-boot-at91/v2020.01-at91+gitAUTOINC+0e1d1b6efb-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0 Output:
Applying patch 0001-add_env_ubi_and_part.patch
patching file configs/sama5d3_xplained_nandflash_defconfig
Hunk #1 succeeded at 51 with fuzz 2 (offset 6 lines).
Hunk #2 FAILED at 88.
1 out of 2 hunks FAILED -- rejects in file configs/sama5d3_xplained_nandflash_defconfig
Patch 0001-add_env_ubi_and_part.patch does not apply (enforce with -f)
```
---
### Author:  [@drewmoseley](https://hub.mender.io/u/drewmoseley)
#### Post date: [September 16, 2020, 3:46pm UTC](https://hub.mender.io/t/yoctosama5d3-mender-artifact-download-fails/2425/14 "2020-09-16T15:46:01Z")
It looks like the patch sama5d3\_xplained\_nandflash\_defconfig needs to be updated against the current U-Boot sources. The easiest way I’ve found to do that is to checkout the git repo and then use “git am” and “patch” to apply the existing patch. The “git am” will not actually apply anything since it refuses to do so unless the patch applies cleanly, but it will setup the git meta-data so that the commit message and information matches the existing patch. Then you use “patch -p1” to apply it. This will succeed with hunk #1 but offset by 6 lines and fail on hunk #2. There will be a ‘\*.rej’ file in the checkout directory with the rejected bits. You’ll need to manually make an equivalent change.
Then you can do “git add -A; git am --continue; git format-patch -1” to have it committed and a new patch generated.
Drew