# Solidrun Clearfog Pro

**URL:** <https://hub.mender.io/t/solidrun-clearfog-pro/1148>\
**Category:** Yocto Project\
**Tags:** yocto, thud, warrior\
**Created:** [October 14, 2019, 8:36pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148 "2019-10-14T20:36:59Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 14, 2019, 8:36pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/1 "2019-10-14T20:36:59Z")

</div>

# Board description

The ClearFog Pro provides access to various I/Os such as GigE port, 5 –port GigE switch, SFP cage, dual mPCIe, M.2, SIM card holder, mikroBUS socket and much more.

Combined, the ClearFog is the perfect board for developers and engineers for networking, routing, storage and IoT gateway applications.

URL: [https://www.solid-run.com/marvell-armada-family/clearfog/](https://www.solid-run.com/marvell-armada-family/clearfog/)  
Wiki: [https://developer.solid-run.com/](https://developer.solid-run.com/)

# Test results

The Yocto Project releases in the table below have been tested by the Mender community. Please update it if you have tested this integration on other [Yocto Project releases](https://wiki.yoctoproject.org/wiki/Releases):

| Yocto Project | Build | Runtime |
| --- | --- | --- |
| thud (2.6) | :test_works: | :test_works: |
| warrior (2.7) | :test_fails: | :test_fails: |

**Build** means that the Yocto Project build using this Mender integration completes without errors and outputs images.  
**Runtime** means that Mender has been verified to work on the board. For U-Boot-based boards, the integration checklist has been verified.

# Getting Started

### Prerequisites

- A supported Linux distribution and dependencies installed on your workstation/laptop as described in the [Yocto Mega Manual](https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#detailed-supported-distros)
  - NOTE. Instructions depend on which Yocto version you intend to use.

- Google repo tool [installed](https://hub.mender.io/t/google-repo/58/2) and in your `PATH`.

## Configuring the build

### Setup Yocto environment

Set the Yocto Project branch you are building for:

```auto
# set to your branch, make sure it is supported (see table above)
export BRANCH="thud"

```

Create a directory for your `mender-clearfog` setup to live in and clone the  
meta information.

```auto
mkdir mender-clearfog && cd mender-clearfog

```

Initialize repo manifest:

```auto
repo init -u https://github.com/mendersoftware/meta-mender-community \
           -m meta-mender-clearfog/scripts/manifest-clearfog.xml \
           -b ${BRANCH}

```

Fetch layers in manifest:

```auto
repo sync

```

## Setup build environment

Initialize the build environment:

```auto
source setup-environment clearfog

```

### Configure Mender server URL (optional)

This section is not required for a successful build but images that are generated by default are only suitable for usage with the Mender client in [Standalone deployments](https://docs.mender.io/architecture/standalone-deployments?target=_blank), due to lack of server configuration.

You can edit the `conf/local.conf` file to provide your Mender server configuration, ensuring the generated images and Mender Artifacts are connecting to the Mender server that you are using. There should already be a commented section in the generated `conf/local.conf` file and you can simply uncomment the relevant configuration options and assign appropriate values to them.

Build for Hosted Mender:

```auto
# To get your tenant token:
# - log in to https://hosted.mender.io
# - click your email at the top right and then "My organization"
# - press the "COPY TO CLIPBOARD"
# - assign content of clipboard to MENDER_TENANT_TOKEN
#
MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "<copy token here>"

```

Build for Mender demo server:

```auto
# https://docs.mender.io/getting-started/create-a-test-environment
#
# Update IP address to match the machine running the Mender demo server
MENDER_DEMO_HOST_IP_ADDRESS = "192.168.0.100"

```

### Building the image

You can now proceed with building an image:

```auto
MACHINE=clearfog-pro bitbake core-image-base

```

Replace `core-image-base` with your desired image target.

### Using the build output

**Note!** The default configuration is booting from a SD card

After a successful build, the images and build artifacts are placed in `tmp/deploy/images/clearfog-pro/`.

- `tmp/deploy/images/clearfog-pro/core-image-base-clearfog-pro.sdimg`
- `tmp/deploy/images/clearfog-pro/core-image-base-clearfog-pro.mender`
- `tmp/deploy/images/clearfog-pro/u-boot-spl-sdhc.kwb`

The disk image with `.sdimg` is used to provision the device storage for devices without Mender running already. Please proceed to [the official documentation on provisioning a new device](https://docs.mender.io/artifacts/provisioning-a-new-device?target=_blank) for steps to do this.

The `u-boot-spl-sdhc.kwb` file is used to provision the device with a Mender compatible U-Boot.

On the other hand, if you already have Mender running on your device and want to deploy a rootfs update using this build, you should use the [Mender Artifact](https://docs.mender.io/architecture/mender-artifacts?target=_blank) files, which have `.mender` suffix. You can either deploy this Artifact in managed mode with the Mender server (upload it under Releases in the server UI) or by using the Mender client only in [Standalone deployments](https://docs.mender.io/architecture/standalone-deployments?target=_blank).

### Boot medium configuration and flashing instructions

Depending on which medium you intend to boot from you need to adjust the `UBOOT_BINARY` variable, please take a look in below link for further information:

> <https://github.com/mirzak/meta-clearfog/blob/master/conf/machine/include/clearfog-common.inc#L8-L18>

Flashing instructions depend-on which boot medium was choosen and you can find more information in the Solidrun documentation,

[https://developer.solid-run.com/knowledge-base/a388-u-boot/#installing-manually](https://developer.solid-run.com/knowledge-base/a388-u-boot/#installing-manually)

# References

- The official [Mender documentation](https://docs.mender.io/) explains how Mender works. This is simply a board-specific complement to the official documentation.

# Known issues

(thud) SolidRun does not provide an official Yocto BSP for the ClearFog range of boards and this integration is based on a layer that I have created which can be found here:

- [https://github.com/mirzak/meta-clearfog](https://github.com/mirzak/meta-clearfog)

I am on the lookout to find a better location for above code.

(warrior) SolidRun have created a Yocto BSP for the Clearfog range of boards and this integration is based on it which can be found here:

- [https://github.com/SolidRun/meta-clearfog](https://github.com/SolidRun/meta-clearfog)

- Currently support for eMMC isn’t implemented, I need to come back and clean up the layer. In the interim you can run the following code during u-boot to reconfigure the board to boot (bypasses the SD-Card check which is required for eMMC)

```auto
setenv bootargs 'root=${mender_kernel_root} rw rootwait'
setenv bootcmd 'run mender_setup; load \${mender_uboot_root} \${kernel_addr_r} /boot/zImage; load \${mender_uboot_root} \${fdt_addr_r} /boot/armada-388-clearfog.dtb; fdt addr \${fdt_addr_r}; fdt resize; fdt rm /soc/internal-regs/sdhci@d8000/ cd-gpios; fdt set /soc/internal-regs/sdhci@d8000/ non-removable; bootz \${kernel_addr_r} - \${fdt_addr_r}; run mender_try_to_recover'
saveenv

```

Hopefully I’ll find some time soon to fix the layer.

* * *

_If this post was useful to you, please press like, or leave a thank you note to the contributor who put valuable time into this and made it available to you. It will be much appreciated!_

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 15, 2019, 12:21am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/2 "2019-10-15T00:21:55Z")

</div>

Having some trouble with the Warrior integration (using the official SolidRun repo). I’m trying to use the automatic u-boot patches and I’m currently stuck with the `MENDER_DTB_NAME=$(mender_get_clean_kernel_devicetree)` line.

I can’t find the definition of mender\_get\_clean\_kernel\_devicetree to work back and isolate the problem, any hints?

I’ve tried moving the KERNEL\_DEVICETREE definition back to the machine conf file and created individual configuration files so the DEVICETREE doesn’t have 3-4 nested dtb files to also help with the boot.cmd script with little luck.

As I write this I notice that I have \_clearfog suffix but that shouldn’t be the issue (still I’ll try removing it).

Anyway thoughts on what the issue might be would be appreciated.

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 15, 2019, 4:03am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/3 "2019-10-15T04:03:38Z")

</div>

Found the code block: [https://github.com/mendersoftware/meta-mender/blob/76a35fd21fd6a0840006564adbeb2dfe01fea40a/meta-mender-core/classes/mender-helpers.bbclass#L207](https://github.com/mendersoftware/meta-mender/blob/76a35fd21fd6a0840006564adbeb2dfe01fea40a/meta-mender-core/classes/mender-helpers.bbclass#L207)

I see I can use MENDER\_DTB\_NAME\_FORCE to define the correct dtb so I’ll use that for now.

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 15, 2019, 9:46pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/4 "2019-10-15T21:46:10Z")

</div>

Well almost compiled. I have hopefully one last error to solve before it’ll build. At the bottom I’ve copied in the error log when it tries to build the sdimag. Taking a look the following snippet stands out:

```auto
mcopy -i /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog--20191015213400-sdimg/tmp.wic.81r3k2n7/rootfs_boot.3.vfat -s /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg/* ::/ returned '1' instead of 0
output: /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg/*: No such file or directory

```

Now I’m not sure if it’s been cleaned up before I check the folder but the `tmp.wic.81r3k2n7` folder doesn’t exist but the file `rootfs_boot.3.vfat` exists in the `core-image-base-clearfog--20191015213400-sdimg` directory so I’m wondering how to overcome the issue.

> **Error Log**
>
> ```auto
> DEBUG: Executing python function prepare_excluded_directories
> DEBUG: 'IMAGE_ROOTFS_EXCLUDE_PATH' is set but 'respect_exclude_path' variable flag is 0 for this image type, so ignoring it
> DEBUG: Python function prepare_excluded_directories finished
> DEBUG: Executing python function set_image_size
> DEBUG: 61648.000000 = 61648 * 1.000000
> DEBUG: 221184.000000 = max(61648.000000, 221184)[221184.000000] + 1
> DEBUG: 221184.000000 = int(221184.000000)
> DEBUG: 221184 = aligned(221184)
> DEBUG: returning 221184
> DEBUG: Python function set_image_size finished
> DEBUG: Executing python function extend_recipe_sysroot
> NOTE: Direct dependencies are ['/home/yocto/clearfog/build/../sources/poky/meta/recipes-core/glibc/ldconfig-native_2.12.1.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/cdrtools/cdrtools-native_3.01.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-connectivity/openssl/openssl_1.1.1b.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/opkg/opkg_0.4.0.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/squashfs-tools/squashfs-tools_git.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/dosfstools/dosfstools_4.1.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-kernel/dtc/dtc_1.4.7.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/meta-clearfog/recipes-kernel/linux/linux-yocto-clearfog_5.1.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-extended/parted/parted_3.2.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/makedevs/makedevs_1.0.1.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/binutils/binutils-cross_2.32.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/qemu/qemuwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-kernel/kmod/kmod-native_git.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-core/glibc/cross-localedef-native_2.29.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/swig/swig_3.0.12.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/opkg-utils/opkg-utils_0.4.0.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-core/glibc/glibc_2.29.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.20.1.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/mklibs/mklibs-native_0.1.44.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-extended/pigz/pigz_2.4.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-bsp/u-boot/u-boot_2019.01.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/bison/bison_3.0.4.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/flex/flex_2.6.0.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/fdisk/gptfdisk_1.0.4.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-core/update-rc.d/update-rc.d_0.8.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.44.5.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/dnf/dnf_4.1.0.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/rpm/rpm_4.14.2.1.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-extended/xz/xz_5.2.4.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-core/coreutils/coreutils_8.30.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/pseudo/pseudo_git.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/python/python-native_2.7.16.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/syslinux/syslinux_6.04-pre2.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/prelink/prelink_git.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/gcc/gcc-cross_8.3.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/gcc/gcc-runtime_8.3.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-devtools/mtools/mtools_4.0.19.bb:do_populate_sysroot', 'virtual:native:/home/yocto/clearfog/build/../sources/poky/meta/recipes-support/lzop/lzop_1.04.bb:do_populate_sysroot', '/home/yocto/clearfog/build/../sources/poky/meta/recipes-core/meta/wic-tools.bb:do_populate_sysroot']
> NOTE: Installed into sysroot: []
> NOTE: Skipping as already exists in sysroot: ['ldconfig-native', 'cdrtools-native', 'openssl-native', 'opkg-native', 'squashfs-tools-native', 'dosfstools-native', 'dtc-native', 'linux-yocto-clearfog', 'parted-native', 'makedevs-native', 'binutils-cross-arm', 'qemuwrapper-cross', 'bmap-tools-native', 'kmod-native', 'cross-localedef-native', 'swig-native', 'opkg-utils-native', 'glibc', 'depmodwrapper-cross', 'btrfs-tools-native', 'mklibs-native', 'pigz-native', 'quilt-native', 'u-boot', 'pbzip2-native', 'bison-native', 'flex-native', 'gptfdisk-native', 'update-rc.d-native', 'e2fsprogs-native', 'dnf-native', 'rpm-native', 'xz-native', 'coreutils-native', 'bc-native', 'pseudo-native', 'python-native', 'syslinux-native', 'prelink-native', 'gcc-cross-arm', 'gcc-runtime', 'kern-tools-native', 'createrepo-c-native', 'mtools-native', 'lzop-native', 'wic-tools', 'systemd-systemctl-native', 'shadow-native', 'autoconf-native', 'automake-native', 'libtool-native', 'pkgconfig-native', 'gnu-config-native', 'libsolv-native', 'libarchive-native', 'zlib-native', 'lz4-native', 'attr-native', 'lzo-native', 'debianutils-native', 'texinfo-dummy-native', 'util-linux-native', 'readline-native', 'ncurses-native', 'gettext-minimal-native', 'qemu-native', 'python3-native', 'python3-setuptools-native', 'python3-six-native', 'gtk-doc-native', 'libpcre-native', 'linux-libc-headers', 'acl-native', 'bzip2-native', 'm4-native', 'popt-native', 'cmake-native', 'ninja-native', 'librepo-native', 'python3-iniparse-native', 'libcomps-native', 'libdnf-native', 'dbus-native', 'perl-native', 'nss-native', 'file-native', 'elfutils-native', 'db-native', 'expat-native', 'gdbm-native', 'sqlite3-native', 'nasm-native', 'binutils-native', 'mpfr-native', 'gmp-native', 'libmpc-native', 'libgcc', 'curl-native', 'libxml2-native', 'glib-2.0-native', 'libffi-native', 'libtirpc-native', 'libnsl2-native', 'unzip-native', 're2c-native', 'gpgme-native', 'libcheck-native', 'gobject-introspection-native', 'libmodulemd-native', 'json-c-native', 'nspr-native', 'groff-native', 'meson-native', 'gettext-native', 'libassuan-native', 'libgpg-error-native', 'libyaml-native']
> DEBUG: Python function extend_recipe_sysroot finished
> DEBUG: Executing shell function do_image_sdimg
> + mkdir -p /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0
> + true
> + install -m 0644 /home/yocto/clearfog/build/tmp/deploy/images/clearfog/uboot.env /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/
> ++ basename /dev/mmcblk0
> + ondisk_dev=mmcblk0
> + wks=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/mender-sdimg.wks
> + rm -f /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/mender-sdimg.wks
> + '[' -n u-boot-clearfog.bin ']'
> + install -m 0644 /home/yocto/clearfog/build/tmp/deploy/images/clearfog/u-boot-clearfog.bin /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/
> ++ expr 1 % 2
> + '[' 1 -ne 0 ']'
> ++ expr 1 + 1
> + bootloader_sector=2
> + bootloader_file=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/u-boot-clearfog.bin-partial
> + dd if=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/u-boot-clearfog.bin of=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/u-boot-clearfog.bin-partial skip=1
> 1035+1 records in
> 1035+1 records out
> 530324 bytes (530 kB, 518 KiB) copied, 0.00638665 s, 83.0 MB/s
> +++ expr 2 '*' 512
> ++ expr 1024 / 1024
> + bootloader_align_kb=1
> ++ stat -c %s /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/u-boot-clearfog.bin-partial
> + bootloader_size=530324
> ++ expr 1 '*' 1024 + 530324
> + bootloader_end=531348
> + '[' 531348 -gt 8388608 ']'
> + cat
> + true
> + '[' -n 8388608 ']'
> ++ expr 8388608 / 1024
> + boot_env_align_kb=8192
> + cat
> ++ expr 8388608 % 1024
> ++ true
> + '[' 0 -ne 0 ']'
> ++ expr 8388608 / 1024
> + alignment_kb=8192
> + '[' msdos = gpt ']'
> + part_type_params=
> ++ echo ' '
> ++ sed -r 's/(^\s*)|(\s*$)//g'
> + IMAGE_BOOT_FILES_STRIPPED=
> + '[' 16 -ne 0 ']'
> + mender_merge_bootfs_and_image_boot_files
> + W=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg
> + rm -rf /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg
> + cp -al /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/rootfs//uboot /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg
> + image_boot_files=' '
> + cat
> + cat
> + '[' 0 -ne 0 ']'
> + cat
> + echo '### Contents of wks file ###'
> ### Contents of wks file ###
> + cat /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/mender-sdimg.wks
> # embed bootloader
> part --source rawcopy --sourceparams="file=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/u-boot-clearfog.bin-partial" --ondisk "mmcblk0" --align 1 --no-table
> part --source rawcopy --sourceparams="file=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/uboot.env" --ondisk "mmcblk0" --align 8192 --no-table
> part --source rootfs --rootfs-dir /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg --ondisk "mmcblk0" --fstype=vfat --label boot --align 8192 --fixed-size 16 --active 
> part --source rawcopy --sourceparams="file=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog.ext4" --ondisk "mmcblk0" --align 8192 --fixed-size 221184k 
> part --source rawcopy --sourceparams="file=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog.ext4" --ondisk "mmcblk0" --align 8192 --fixed-size 221184k 
> part --source rawcopy --sourceparams="file=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog.dataimg" --ondisk "mmcblk0" --align 8192 --fixed-size 128 --mkfs-extraopts='' 
> bootloader --ptable msdos
> + echo '### End of contents of wks file ###'
> ### End of contents of wks file ###
> + outimgname=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog--20191015213400.sdimg
> + wicout=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog--20191015213400-sdimg
> + BUILDDIR=/home/yocto/clearfog/build
> + wic create /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/mender-sdimg.wks --vars /home/yocto/clearfog/build/tmp/sysroots/clearfog/imgdata/ -e core-image-base -o /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog--20191015213400-sdimg/
> INFO: Creating image(s)...
> 
> WARNING: overhead-factor was specified, but size was not, so bitbake variables will be used for the size. In this case both IMAGE_OVERHEAD_FACTOR and --overhead-factor will be applied
> ERROR: _exec_cmd: export PATH=/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/sbin:/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/sbin:/home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot-native/usr/bin:$PATH;mcopy -i /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog--20191015213400-sdimg/tmp.wic.81r3k2n7/rootfs_boot.3.vfat -s /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg/* ::/ returned '1' instead of 0
> output: /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg/*: No such file or directory
> 
> + bb_exit_handler
> + ret=1
> + case $ret in
> + case $BASH_VERSION in
> + echo 'WARNING: /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/temp/run.do_image_sdimg.62730:1 exit 1 from '\''BUILDDIR="/home/yocto/clearfog/build" wic create "$wks" --vars "/home/yocto/clearfog/build/tmp/sysroots/clearfog/imgdata/" -e "core-image-base" -o "$wicout/"'\'''
> WARNING: /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/temp/run.do_image_sdimg.62730:1 exit 1 from 'BUILDDIR="/home/yocto/clearfog/build" wic create "$wks" --vars "/home/yocto/clearfog/build/tmp/sysroots/clearfog/imgdata/" -e "core-image-base" -o "$wicout/"'
> + exit 1
> ERROR: Function failed: do_image_sdimg (log file is located at /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/temp/log.do_image_sdimg.62730)
> 
> ```

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [October 16, 2019, 8:17pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/5 "2019-10-16T20:17:00Z")

</div>

Hm, I can not spot anything that stands out to me. Can you share your `local.conf`?

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 16, 2019, 9:13pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/6 "2019-10-16T21:13:39Z")

</div>

See below:

> **local.conf**
>
> ```auto
> #
> # This file is your local configuration file and is where all local user settings
> # are placed. The comments in this file give some guide to the options a new user
> # to the system might want to change but pretty much any configuration option can
> # be set in this file. More adventurous users can look at local.conf.extended
> # which contains other examples of configuration which can be placed in this file
> # but new users likely won't need any of them initially.
> #
> # Lines starting with the '#' character are commented out and in some cases the
> # default values are provided as comments to show people example syntax. Enabling
> # the option is a question of removing the # character and making any change to the
> # variable as required.
> 
> #
> # Machine Selection
> #
> # You need to select a specific machine to target the build with. There are a selection
> # of emulated machines available which can boot and run in the QEMU emulator:
> #
> #MACHINE ?= "qemuarm"
> #MACHINE ?= "qemuarm64"
> #MACHINE ?= "qemumips"
> #MACHINE ?= "qemumips64"
> #MACHINE ?= "qemuppc"
> #MACHINE ?= "qemux86"
> #MACHINE ?= "qemux86-64"
> #
> # There are also the following hardware board target machines included for 
> # demonstration purposes:
> #
> #MACHINE ?= "beaglebone-yocto"
> #MACHINE ?= "genericx86"
> #MACHINE ?= "genericx86-64"
> #MACHINE ?= "mpc8315e-rdb"
> #MACHINE ?= "edgerouter"
> #
> # This sets the default machine to be qemux86 if no other machine is selected:
> MACHINE ??= "qemux86"
> 
> #
> # Where to place downloads
> #
> # During a first build the system will download many different source code tarballs
> # from various upstream projects. This can take a while, particularly if your network
> # connection is slow. These are all stored in DL_DIR. When wiping and rebuilding you
> # can preserve this directory to speed up this part of subsequent builds. This directory
> # is safe to share between multiple builds on the same machine too.
> #
> # The default is a downloads directory under TOPDIR which is the build directory.
> #
> #DL_DIR ?= "${TOPDIR}/downloads"
> 
> #
> # Where to place shared-state files
> #
> # BitBake has the capability to accelerate builds based on previously built output.
> # This is done using "shared state" files which can be thought of as cache objects
> # and this option determines where those files are placed.
> #
> # You can wipe out TMPDIR leaving this directory intact and the build would regenerate
> # from these files if no changes were made to the configuration. If changes were made
> # to the configuration, only shared state files where the state was still valid would
> # be used (done using checksums).
> #
> # The default is a sstate-cache directory under TOPDIR.
> #
> #SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
> 
> #
> # Where to place the build output
> #
> # This option specifies where the bulk of the building work should be done and
> # where BitBake should place its temporary files and output. Keep in mind that
> # this includes the extraction and compilation of many applications and the toolchain
> # which can use Gigabytes of hard disk space.
> #
> # The default is a tmp directory under TOPDIR.
> #
> #TMPDIR = "${TOPDIR}/tmp"
> 
> #
> # Default policy config
> #
> # The distribution setting controls which policy settings are used as defaults.
> # The default value is fine for general Yocto project use, at least initially.
> # Ultimately when creating custom policy, people will likely end up subclassing 
> # these defaults.
> #
> DISTRO ?= "poky"
> # As an example of a subclass there is a "bleeding" edge policy configuration
> # where many versions are set to the absolute latest code from the upstream 
> # source control systems. This is just mentioned here as an example, its not
> # useful to most new users.
> # DISTRO ?= "poky-bleeding"
> 
> #
> # Package Management configuration
> #
> # This variable lists which packaging formats to enable. Multiple package backends
> # can be enabled at once and the first item listed in the variable will be used
> # to generate the root filesystems.
> # Options are:
> # - 'package_deb' for debian style deb files
> # - 'package_ipk' for ipk files are used by opkg (a debian style embedded package manager)
> # - 'package_rpm' for rpm style packages
> # E.g.: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk"
> # We default to rpm:
> PACKAGE_CLASSES ?= "package_rpm"
> 
> #
> # SDK target architecture
> #
> # This variable specifies the architecture to build SDK items for and means
> # you can build the SDK packages for architectures other than the machine you are
> # running the build on (i.e. building i686 packages on an x86_64 host).
> # Supported values are i686 and x86_64
> #SDKMACHINE ?= "i686"
> 
> #
> # Extra image configuration defaults
> #
> # The EXTRA_IMAGE_FEATURES variable allows extra packages to be added to the generated
> # images. Some of these options are added to certain image types automatically. The
> # variable can contain the following options:
> # "dbg-pkgs" - add -dbg packages for all installed packages
> # (adds symbol information for debugging/profiling)
> # "src-pkgs" - add -src packages for all installed packages
> # (adds source code for debugging)
> # "dev-pkgs" - add -dev packages for all installed packages
> # (useful if you want to develop against libs in the image)
> # "ptest-pkgs" - add -ptest packages for all ptest-enabled packages
> # (useful if you want to run the package test suites)
> # "tools-sdk" - add development tools (gcc, make, pkgconfig etc.)
> # "tools-debug" - add debugging tools (gdb, strace)
> # "eclipse-debug" - add Eclipse remote debugging support
> # "tools-profile" - add profiling tools (oprofile, lttng, valgrind)
> # "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
> # "debug-tweaks" - make an image suitable for development
> # e.g. ssh root access has a blank password
> # There are other application targets that can be used here too, see
> # meta/classes/image.bbclass and meta/classes/core-image.bbclass for more details.
> # We default to enabling the debugging tweaks.
> EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
> 
> #
> # Additional image features
> #
> # The following is a list of additional classes to use when building images which
> # enable extra features. Some available options which can be included in this variable
> # are:
> # - 'buildstats' collect build statistics
> # - 'image-mklibs' to reduce shared library files size for an image
> # - 'image-prelink' in order to prelink the filesystem image
> # NOTE: if listing mklibs & prelink both, then make sure mklibs is before prelink
> # NOTE: mklibs also needs to be explicitly enabled for a given image, see local.conf.extended
> USER_CLASSES ?= "buildstats image-mklibs image-prelink"
> 
> #
> # Runtime testing of images
> #
> # The build system can test booting virtual machine images under qemu (an emulator)
> # after any root filesystems are created and run tests against those images. It can also
> # run tests against any SDK that are built. To enable this uncomment these lines.
> # See classes/test{image,sdk}.bbclass for further details.
> #IMAGE_CLASSES += "testimage testsdk"
> #TESTIMAGE_AUTO_qemuall = "1"
> 
> #
> # Interactive shell configuration
> #
> # Under certain circumstances the system may need input from you and to do this it
> # can launch an interactive shell. It needs to do this since the build is
> # multithreaded and needs to be able to handle the case where more than one parallel
> # process may require the user's attention. The default is iterate over the available
> # terminal types to find one that works.
> #
> # Examples of the occasions this may happen are when resolving patches which cannot
> # be applied, to use the devshell or the kernel menuconfig
> #
> # Supported values are auto, gnome, xfce, rxvt, screen, konsole (KDE 3.x only), none
> # Note: currently, Konsole support only works for KDE 3.x due to the way
> # newer Konsole versions behave
> #OE_TERMINAL = "auto"
> # By default disable interactive patch resolution (tasks will just fail instead):
> PATCHRESOLVE = "noop"
> 
> #
> # Disk Space Monitoring during the build
> #
> # Monitor the disk space during the build. If there is less that 1GB of space or less
> # than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
> # shutdown the build. If there is less that 100MB or 1K inodes, perform a hard abort
> # of the build. The reason for this is that running completely out of space can corrupt
> # files and damages the build in ways which may not be easily recoverable.
> # It's necesary to monitor /tmp, if there is no space left the build will fail
> # with very exotic errors.
> BB_DISKMON_DIRS ??= "\
> STOPTASKS,${TMPDIR},1G,100K \
> STOPTASKS,${DL_DIR},1G,100K \
> STOPTASKS,${SSTATE_DIR},1G,100K \
> STOPTASKS,/tmp,100M,100K \
> ABORT,${TMPDIR},100M,1K \
> ABORT,${DL_DIR},100M,1K \
> ABORT,${SSTATE_DIR},100M,1K \
> ABORT,/tmp,10M,1K"
> 
> #
> # Shared-state files from other locations
> #
> # As mentioned above, shared state files are prebuilt cache data objects which can
> # used to accelerate build time. This variable can be used to configure the system
> # to search other mirror locations for these objects before it builds the data itself.
> #
> # This can be a filesystem directory, or a remote url such as http or ftp. These
> # would contain the sstate-cache results from previous builds (possibly from other
> # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the
> # cache locations to check for the shared objects.
> # NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
> # at the end as shown in the examples below. This will be substituted with the
> # correct path within the directory structure.
> #SSTATE_MIRRORS ?= "\
> #file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \
> #file://.* file:///some/local/dir/sstate/PATH"
> 
> #
> # Yocto Project SState Mirror
> #
> # The Yocto Project has prebuilt artefacts available for its releases, you can enable
> # use of these by uncommenting the following line. This will mean the build uses
> # the network to check for artefacts at the start of builds, which does slow it down
> # equally, it will also speed up the builds by not having to build things if they are
> # present in the cache. It assumes you can download something faster than you can build it
> # which will depend on your network.
> #
> #SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"
> 
> #
> # Qemu configuration
> #
> # By default qemu will build with a builtin VNC server where graphical output can be
> # seen. The two lines below enable the SDL backend too. By default libsdl2-native will
> # be built, if you want to use your host's libSDL instead of the minimal libsdl built
> # by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
> PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
> PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
> #ASSUME_PROVIDED += "libsdl2-native"
> 
> # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
> # track the version of this file when it was generated. This can safely be ignored if
> # this doesn't mean anything to you.
> CONF_VERSION = "1"
> 
> # Appended fragment from meta-mender-community/templates
> 
> # This really saves a lot of disk space!
> INHERIT += "rm_work"
> 
> # The name of the disk image and Artifact that will be built.
> # This is what the device will report that it is running, and different updates
> # must have different names because Mender will skip installation of an Artifact
> # if it is already installed.
> MENDER_ARTIFACT_NAME = "release-1"
> 
> INHERIT += "mender-full"
> 
> DISTRO_FEATURES_append = " systemd"
> VIRTUAL-RUNTIME_init_manager = "systemd"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> VIRTUAL-RUNTIME_initscripts = ""
> 
> # Build for Hosted Mender
> #
> # To get your tenant token:
> # - log in to https://hosted.mender.io
> # - click your email at the top right and then "My organization"
> # - press the "COPY TO CLIPBOARD"
> # - assign content of clipboard to MENDER_TENANT_TOKEN
> #
> #MENDER_SERVER_URL = "https://hosted.mender.io"
> #MENDER_TENANT_TOKEN = ""
> 
> # Build for Mender demo server
> #
> # https://docs.mender.io/getting-started/create-a-test-environment
> #
> # Uncomment below and update IP address to match the machine running the
> # Mender demo server
> #MENDER_DEMO_HOST_IP_ADDRESS = "192.168.0.100"
> 
> # Build for Mender production setup (on-prem)
> #
> # https://docs.mender.io/artifacts/building-for-production
> #
> # Uncomment below and update the URL to match your configured domain
> # name and provide the path to the generated server.crt file.
> #
> # NOTE! It is recommend that you provide below information in your custom
> # Yocto layer and this is only for demo purposes. See linked documentation
> # for additional information.
> #MENDER_SERVER_URL = "https://docker.mender.io"
> #FILESEXTRAPATHS_prepend_pn-mender := "<DIRECTORY-CONTAINING-server.crt>:"
> #SRC_URI_append_pn-mender = " file://server.crt"
> 
> # Mender storage configuration
> #
> # More details on these variables is available at
> # https://docs.mender.io/devices/yocto-project/partition-configuration#configuring-storage
> #
> # Also, please be sure to check other config files as other
> # layers, config fragments, etc may attempt to set values
> # for specific platforms. Using "bitbake -e <image-name>"
> # can help determine which files are setting these values
> # in a given configuration.
> #
> # MENDER_STORAGE_TOTAL_SIZE_MB = "2048"
> # MENDER_BOOT_PART_SIZE_MB = "16"
> # MENDER_DATA_PART_SIZE_MB = "1024"
> # MENDER_STORAGE_DEVICE = "/dev/mmcblk0"
> # MENDER_BOOT_PART = "${MENDER_STORAGE_DEVICE_BASE}1"
> # MENDER_DATA_PART = "${MENDER_STORAGE_DEVICE_BASE}4"
> # MENDER_ROOTFS_PART_A = "${MENDER_STORAGE_DEVICE_BASE}2"
> # MENDER_ROOTFS_PART_B = "${MENDER_STORAGE_DEVICE_BASE}3"
> # Appended fragment from meta-mender-community/meta-mender-clearfog/templates
> 
> # Supported Machine Types:
> # - clearfog
> # - clearfog-gtr-s4
> # - clearfog-gtr-l8
> MACHINE ?= "clearfog"
> 
> # Have to manually specify the DTB file to use with Mender
> 
> # Supported models:
> 
> # armada-388-clearfog.dtb - Clearfog
> # armada-388-clearfog-base.dtb - Clearfog Base
> # armada-388-clearfog-pro.dtb - Clearfog Pro
> # armada-388-clearfog-gtr-s4.dtb - Clearfog GTR S4
> # armada-388-clearfog-gtr-l8.dtb - Clearfog GTR L8
> #
> MENDER_DTB_NAME_FORCE ?= "armada-388-clearfog-pro.dtb"
> 
> # Set the storage medium
> # Refer: https://github.com/mirzak/meta-clearfog/blob/master/conf/machine/include/clearfog-common.inc#L8-L18
> UBOOT_BINARY ?= "u-boot-spl-mmc.kwb"
> 
> IMAGE_INSTALL_append = " kernel-image kernel-devicetree"
> 
> MENDER_IMAGE_BOOTLOADER_FILE = "u-boot-${MACHINE}.bin"
> MENDER_IMAGE_BOOTLOADER_BOOTSECTOR_OFFSET = "1"
> 
> MENDER_FEATURES_ENABLE_append = " mender-uboot mender-image-sd"
> MENDER_FEATURES_DISABLE_append = " mender-grub mender-image-uefi"
> 
> ```

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 16, 2019, 9:20pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/7 "2019-10-16T21:20:21Z")

</div>

I’m currently building:

> **[Valks/meta-mender-community](https://github.com/Valks/meta-mender-community/tree/dev)**
>
> Community supported integration layers for Mender on various boards - Valks/meta-mender-community

I have a separate meta-mender-clearfog layer (for the moment) as I try to make the changes needed to get the official solidrun meta-clearfog working:

> **[Valks/meta-mender-clearfog](https://github.com/Valks/meta-mender-clearfog/tree/warrior)**
>
> Support layer for clearfog boards when using mender - Valks/meta-mender-clearfog

```auto
repo init -u https://github.com/valks/meta-mender-community -m meta-mender-clearfog/scripts/manifest-clearfog.xml -b dev
repo sync
. ./setup-environment clearfog
bitbake core-image-base

```

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 16, 2019, 9:28pm UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/8 "2019-10-16T21:28:59Z")

</div>

Looking deeper it’s even stranger, the only place I can see a use of mcopy is (new file in the warrior branch):

> <https://github.com/mendersoftware/meta-mender/blob/d6a24868fca3e4d9839e71fb65a02de95e28df64/meta-mender-core/classes/mender-bootimg.bbclass#L13>

But the command doesn’t match what I see in the log:

```auto
mcopy -i "${WORKDIR}/boot.vfat" -s "$i" ::/

```

```auto
mcopy -i /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/deploy-core-image-base-image-complete/core-image-base-clearfog--20191016203146-sdimg/tmp.wic.pulzatmg/rootfs_boot.3.vfat -s /home/yocto/clearfog/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-base/1.0-r0/bootfs.image_sdimg/* ::/

```

When I manually run the command it gives me an error but if I remove the \* at the end of the destination path it works (but nothing is copied)  
Also if I change the `rootfs_boot.3.vfat` path to remove the `tmp.wic.pulzatmg` folder which doesn’t exist I still don’t have any files copied (`rootfs_boot.3.vfat` exists in the `core-image-base-clearfog--20191016203146-sdimg` folder).

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 17, 2019, 12:42am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/9 "2019-10-17T00:42:23Z")

</div>

Well as I keep digging deeper it the command comes from the poky layer (not what I linked above) and the problem seems to start from the `bootfs.image_sdimage` folder not containing the files needed to create the `rootfs_boot.3.vfat` file.

That said to test I copied a file into the folder and ran the command only to get a different error:

```auto
Cannot initialize '::'
Bad target ::/

```

So I’ll try and figure out where the files are created for `bootfs.image_sdimage` then go from there hoping the build script will correct whatever issue is causing the latest problem.

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 17, 2019, 4:33am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/10 "2019-10-17T04:33:13Z")

</div>

Any thoughts or help with this one would be appreciated.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [October 17, 2019, 9:28am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/11 "2019-10-17T09:28:04Z")

</div>

Oki, now I think I know what is going on. I think this relates to the fact that `IMAGE_BOOT_FILES` is empty because this board does not require any files in the boot vfat partition to boot. This is a bug in `mender-bootimg.bblcass`, which should check this variable.

But quick workaround is to add:

```auto
# This is just a dummy value to silence the error
IMAGE_BOOT_FILES = "${UBOOT_BINARY}"

```

or you can disable the vfat boot partition (since it is not required for this board):

```auto
MENDER_BOOT_PART_SIZE_MB = "0"

```

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 22, 2019, 4:29am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/12 "2019-10-22T04:29:41Z")

</div>

Well I could use some advise. Trying to update to warrior and I thought I’d try and slim down the layer as much as possible to minimize changes with future versions.

With that said I can compile easy enough but booting is another issue. It get stuck when booting:

```auto
U-Boot SPL 2019.01 (Oct 22 2019 - 00:53:03 +0000)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane # | Speed | Type |
 --------------------------------
 | 0 | 3 | SATA0 |
 | 1 | 0 | SGMII1 |
 | 2 | 5 | PCIe1 |
 | 3 | 5 | USB3 HOST1 |
 | 4 | 5 | PCIe2 |
 | 5 | 0 | SGMII2 |
 --------------------------------
PCIe, Idx 1: detected no link
PCIe, Idx 2: detected no link
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-18.09.2
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from MMC1

```

As an interesting aside if I don’t have any devices connected in the PCIe bus I get a different bit of gibberish each time I load the u-boot binary, i.e. `0▒▒4▒▒s0▒▒s ▒▒ ▒+▒M┫▒`.

Any thoughts or experience from getting the thud branch working as to why it isn’t working?

Currently I’m working out of: [https://github.com/Valks/meta-mender-community/commits/dev](https://github.com/Valks/meta-mender-community/commits/dev)  
and have it pointing to: [https://github.com/Valks/meta-clearfog/tree/warrior](https://github.com/Valks/meta-clearfog/tree/warrior)  
This is just a direct clone of the SolidRun repo at the moment, just using a fork so I can try changes.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [October 22, 2019, 6:57am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/13 "2019-10-22T06:57:04Z")

</div>

> [@Valks](#):
>
> Any thoughts or experience from getting the thud branch working as to why it isn’t working?

Nothing specific. How does the configuration of U-Boot work now? It seems to use the default (SDHC)? Are you trying to boot from eMMC or SD card? Does it boot without meta-mender?

I would at this stage take a step back and focus on the U-Boot source code alone (leaving Yocto out of it for now) to try to bisect the problem.

You can get the patch that meta-mender generated with:

```auto
bitbake -c save_mender_auto_configured_patch u-boot

```

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 24, 2019, 4:51am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/14 "2019-10-24T04:51:52Z")

</div>

So after a few round trips the answer was right in front of me (naturally):

> <https://github.com/SolidRun/meta-clearfog/blob/master/recipes-bsp/u-boot/u-boot/emmc.cfg#L1>

Default is set to `0x141` which points to the SD Card slot and the emmc.cfg file changes it to `0x140` for eMMC. So with that sorted I can compile and boot using:

```auto
poky/meta
poky/meta-poky
poky/meta-yocto-bsp
/meta-clearfog

```

To make it configurable I added an extra variable `BOOT_MEDIA` in my fork of `meta-clearfog` and did the required changes in a fork of `meta-mender-community`. Thinking it was all good (since I manged to at least compile before) I gave it a go and a new unexpected error occurred 😡.

```auto
ERROR: mender-artifact-native-3.2.0-r0 do_compile: oe_runmake failed ERROR: mender-artifact-native-3.2.0-r0 do_compile: Function failed: do_compile (log file is located at /home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/temp/log.do_compile.43085) ERROR: Logfile of failure stored in: /home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/temp/log.do_compile.43085 Log data follows: | DEBUG: Executing shell function do_compile | GOARCH="amd64" | GOBIN="" | GOCACHE="/home/yocto/.cache/go-build" | GOEXE="" | GOFLAGS="" | GOHOSTARCH="amd64" | GOHOSTOS="linux" | GOOS="linux" | GOPATH="/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/build:/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib/x86_64-linux/go" | GOPROXY="" | GORACE="" | GOROOT="/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib/go"
| GOTMPDIR="/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/go-tmp"
| GOTOOLDIR="/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib/go/pkg/tool/linux_amd64"
| GCCGO="gccgo"
| CC="gcc"
| CXX="g++"
| CGO_ENABLED="1"
| GOMOD=""
| CGO_CFLAGS="-isystem/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/include -O2 -pipe"
| CGO_CPPFLAGS="-isystem/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/include"
| CGO_CXXFLAGS="-isystem/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/include -O2 -pipe"
| CGO_FFLAGS="-g -O2"
| CGO_LDFLAGS="-L/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib -L/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/lib -Wl,--enable-new-dtags -Wl,-rpath-link,/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/lib -Wl,-rpath,/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib -Wl,-rpath,/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/lib -Wl,-O1 -Wl,--allow-shlib-undefined -Wl,--dynamic-linker=/home/yocto/clearfog/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2"
| PKG_CONFIG="pkg-config"
| GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/go-tmp/go-build937725416=/tmp/go-build -gno-record-gcc-switches"
| NOTE: make -j 24 GOPATH=/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/build:/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib/x86_64-linux/go -C /home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/build/src/github.com/mendersoftware/mender-artifact V=1 install
| make: Entering directory '/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/git/src/github.com/mendersoftware/mender-artifact'
| cd cli/mender-artifact && go install -ldflags "-X main.Version=3.2.0" -v
| # github.com/mendersoftware/mender-artifact/cli/mender-artifact
| /home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/recipe-sysroot-native/usr/lib/go/pkg/tool/linux_amd64/link: running gcc failed: exit status 1
| /home/yocto/clearfog/build/tmp/hosttools/ld: cannot find -llzma
| /home/yocto/clearfog/build/tmp/hosttools/ld: cannot find -llzma
| collect2: error: ld returned 1 exit status
|
| Makefile:74: recipe for target 'install' failed
| make: *** [install] Error 2
| make: Leaving directory '/home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/git/src/github.com/mendersoftware/mender-artifact'
| ERROR: oe_runmake failed
| WARNING: /home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/temp/run.do_compile.43085:1 exit 1 from 'exit 1'
| ERROR: Function failed: do_compile (log file is located at /home/yocto/clearfog/build/tmp/work/x86_64-linux/mender-artifact-native/3.2.0-r0/temp/log.do_compile.43085)
ERROR: Task (virtual:native:/home/yocto/clearfog/build/../sources/meta-mender/meta-mender-core/recipes-mender/mender-artifact/mender-artifact_3.2.0.bb:do_compile) failed with exit code '1' NOTE: Tasks Summary: Attempted 1809 tasks of which 1613 didn't need to be rerun and 1 failed. Summary: 1 task failed: virtual:native:/home/yocto/clearfog/build/../sources/meta-mender/meta-mender-core/recipes-mender/mender-artifact/mender-artifact_3.2.0.bb:do_compile Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

```

I’m completely lost as to what went wrong here, especially since I can compile the raspberrypi just fine.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [October 24, 2019, 6:19am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/15 "2019-10-24T06:19:37Z")

</div>

Well for some reason it can not find the `lzma` library, unclear why it would not as this line should take care of it,

> <https://github.com/mendersoftware/meta-mender/blob/warrior/meta-mender-core/recipes-mender/mender-artifact/mender-artifact_3.2.0.bb#L25>

Can you try clearing the sstate cache for `mender-artifact-native`?

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 24, 2019, 6:32am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/16 "2019-10-24T06:32:41Z")

</div>

I actually completely wiped everything and started clean (from repo init) and still had the issue.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [October 24, 2019, 6:38am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/17 "2019-10-24T06:38:03Z")

</div>

Hm, could it be that it is picking trying to pick it from your host machine. Did something change there recently?

Can you send me the set of commands you run to setup things (repo init …) and I can try on my machine

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 24, 2019, 6:52am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/18 "2019-10-24T06:52:43Z")

</div>

repo init -u [https://github.com/Valks/meta-mender-community](https://github.com/Valks/meta-mender-community) - m meta-mender-clearfog/scripts/manifest-clearfog.xml - b dev  
repo sync  
source setup-environment clearfog  
bitbake core-image-base  
(can alos build minimal)

Wrote that on my phone so if there’s a minor typo read between the lines.

---

<div class="post-metadata">

**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\
**Post date:** [October 24, 2019, 7:07am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/19 "2019-10-24T07:07:45Z")

</div>

Hm, I am not getting any errors regarding the `mender-artifact-native` recipe. My environment is a Debian 9 VM.

Though another error shows up to me:

```auto
ERROR: u-boot-1_2019.01-r0 do_configure: Function failed: do_configure (log file is located at /home/admin/tmp/build/tmp/work/clearfog-poky-linux-gnueabi/u-boot/1_2019.01-r0/temp/log.do_configure.21940)
ERROR: Logfile of failure stored in: /home/admin/tmp/build/tmp/work/clearfog-poky-linux-gnueabi/u-boot/1_2019.01-r0/temp/log.do_configure.21940
Log data follows:
| DEBUG: Executing shell function do_configure
| The base file '/home/admin/tmp/build/tmp/work/clearfog-poky-linux-gnueabi/u-boot/1_2019.01-r0/build/.config' does not exist. Exit.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at /home/admin/tmp/build/tmp/work/clearfog-poky-linux-gnueabi/u-boot/1_2019.01-r0/temp/log.do_configure.21940)
ERROR: Task (/home/admin/tmp/build/../sources/poky/meta/recipes-bsp/u-boot/u-boot_2019.01.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1755 tasks of which 1431 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /home/admin/tmp/build/../sources/poky/meta/recipes-bsp/u-boot/u-boot_2019.01.bb:do_configure
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

```

---

<div class="post-metadata">

**Author:** ![Valks](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/valks/32/321_2.png) [@Valks](https://hub.mender.io/u/Valks)\
**Post date:** [October 24, 2019, 7:32am UTC](https://hub.mender.io/t/solidrun-clearfog-pro/1148/20 "2019-10-24T07:32:36Z")

</div>

Hmm that’s a new one, not sure why that’s happening. That said my patch to fix MMC does try to modify .config.

Probably worth (for testing) removing the `do_configure_prepend` `function in the meta-clearfog recipes-bsp/u-boot/u-boot_2019.01.bbappend`. If what I did is causing an issue that will overcome it.

> <https://github.com/Valks/meta-clearfog/commit/a8fd5841f7836253259d284c76e2ad21d21ade7b>

Hopefully that’ll let you see the issue I’m having.

[Next page](https://hub.mender.io/t/solidrun-clearfog-pro/1148.md?page=2)