# Simple configuration (dunfell)

**URL:** <https://hub.mender.io/t/simple-configuration-dunfell/2991>\
**Category:** General Discussions\
**Created:** [December 15, 2020, 12:43pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991 "2020-12-15T12:43:07Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 12:43pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/1 "2020-12-15T12:43:07Z")

</div>

Hello! I am trying to build a simple **yocto** build with **core-image-sato**. Everything is perfect and the image is bootable until I add **mender** to the build. When building with **mender** , all grub options disappear except one - to go to the firmware settings.

 ![Screenshot from 2020-12-15 14-51-03](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/1X/322c2f167a2868f3f1ff6f5257230d9c7c626a05.png)

There are the layers:

```
BBLAYERS ?= " \
  ../poky/meta \
  ../poky/meta-poky \
  ../poky/meta-yocto-bsp \
  ../poky/meta-intel \
  ../poky/meta-mender/meta-mender-core \
"

```

Should I just include the **meta-mender-demo** layer? I think it could be something because of the layer priorities?

```
layer path priority
==========================================================================
meta /poky/meta 5
meta-poky /poky/meta-poky 5
meta-yocto-bsp /poky/meta-yocto-bsp 5
meta-intel /poky/meta-intel 5
meta-mender-core /poky/meta-mender/meta-mender-core 6

```

I would even disable any options from **grub menu**. Just to load straight to the system. This way **psplash** would hide all system logs, right?

All of the layers are from their **dunfell** branch. Seems that’s the latest which **mender** supports.

Thanks for the help!

---

<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:** [December 15, 2020, 2:03pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/2 "2020-12-15T14:03:17Z")

</div>

Do you add any of the configuration options for mender in e.g local.conf?

Things that are covered here,

[https://docs.mender.io/system-updates-yocto-project/build-for-demo#configuring-the-build-1](https://docs.mender.io/system-updates-yocto-project/build-for-demo#configuring-the-build-1)

> Should I just include the **meta-mender-demo** layer? I think it could be something because of the layer priorities?

This is not strictly required, but can easy with testing.

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 2:06pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/3 "2020-12-15T14:06:13Z")

</div>

Thanks for the fast response! These are the settings I set in the `local.conf`

```
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 = ""
ARTIFACTIMG_FSTYPE = "ext4"

MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "XXXXX" // the token from my mender acc
MENDER_STORAGE_TOTAL_SIZE_MB = "2048"
MENDER_STORAGE_DEVICE = "/dev/sdb" // because boot from usb device

```

I just tested with **meta-mender-demo** but the result is the same.

---

<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:** [December 15, 2020, 2:08pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/4 "2020-12-15T14:08:58Z")

</div>

Looks good,

And which image do you use to provision the device?

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 2:11pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/5 "2020-12-15T14:11:50Z")

</div>

The image I try to build is **core-image-full-cmdline**. Build Configuration:

```
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "intel-corei7-64"
DISTRO = "poky"
DISTRO_VERSION = "3.1.4"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU = ""
meta                 
meta-poky            
meta-yocto-bsp = "dunfell:861cfcd52f0b769772c3726530210f2f43c3449b"
meta-intel = "dunfell:7fe349c03bad8a2609429b6783c0909d2aef3694"
meta-mender-core     
meta-mender-demo = "dunfell:cc1fdd90820bf8912007b399217bdc3278473165"
```

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 2:16pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/6 "2020-12-15T14:16:32Z")

</div>

Sorry, didn’t get it. **.uefiimg**.

---

<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:** [December 15, 2020, 2:48pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/7 "2020-12-15T14:48:27Z")

</div>

I can not spot anything obvious. It all looks ok to me.

Normally you would not get any menus in GRUB with meta-mender, it would just boot. The fact that it gets to the “Firmware Interface” means that something went wrong in `grub.cfg`

I would check the grub.cfg file on the boot part of your USB to try to spot anything. You could also enable it to halt at strategic locations to prevent GRUB from clearing the buffer, this should probably tell you what is actually going wrong

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 3:03pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/8 "2020-12-15T15:03:39Z")

</div>

In the **grub.cfg** file seems everything is okey and all come from mender. Will try to format the USB and clean the bitbake cache and try again to see what would be the result.  
Something interesting in the grub file I found:

```
mender_kernel_root_base=/dev/mmcblk0p

```

But in the **local.conf** I already set to /dev/sdb - or it is something different?

---

<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:** [December 15, 2020, 4:03pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/9 "2020-12-15T16:03:44Z")

</div>

> [@johny](#):
>
> `MENDER_STORAGE_DEVICE = "/dev/sdb"`

This looks correct, so indeed it looks strange that `grub.cfg` does not represent this.

Can you check in your build e.g `bitbake core-image-sate -e | grep ^MENDER_STORAGE_DEVICE`

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 5:26pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/10 "2020-12-15T17:26:30Z")

</div>

```
MENDER_STORAGE_DEVICE="/dev/sdb"
MENDER_STORAGE_DEVICE_BASE="/dev/sdb"
MENDER_STORAGE_DEVICE_BASE_DEFAULT="/dev/sdb"
MENDER_STORAGE_DEVICE_BASE_DEFAULT_mender-ubi="/dev/sdb_"
MENDER_STORAGE_DEVICE_DEFAULT="/dev/mmcblk0"
MENDER_STORAGE_DEVICE_DEFAULT_mender-ubi="ubi0"

```

Seems it is ok as `mender_kernel_root_base=${MENDER_STORAGE_DEVICE_BASE}` should set the right device.

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [December 15, 2020, 6:50pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/11 "2020-12-15T18:50:04Z")

</div>

As I use `meta-intel` it includes it’s own grub efi. And from this:

```
# Set EFI_PROVIDER. Not all MACHINE configs use it but notably
# intel-corei7-64 does and without this we use the default of systemd-boot.

EFI_PROVIDER ?= "${_MENDER_EFI_PROVIDER_DEFAULT}"
_MENDER_EFI_PROVIDER_DEFAULT = ""
_MENDER_EFI_PROVIDER_DEFAULT_mender-grub = "grub-efi"
_MENDER_EFI_PROVIDER_DEFAULT_mender-grub_mender-bios = ""

```

mender disables it with `_MENDER_EFI_PROVIDER_DEFAULT = ""`, isn’t it? But after running `bitbake core-image-full-cmdline -e | grep ^_MENDER_EFI_PROVIDER_DEFAULT` I got this:

```
_MENDER_EFI_PROVIDER_DEFAULT="grub-efi"
_MENDER_EFI_PROVIDER_DEFAULT_mender-grub="grub-efi"
_MENDER_EFI_PROVIDER_DEFAULT_mender-grub_mender-bios=""

```

Respectively, `EFI_PROVIDER="systemd-boot"`.

If I am right there is an issue setting `_MENDER_EFI_PROVIDER_DEFAULT`.

Something else I just noticed while building is this warning:

```
WARNING: mender-client-2.4.1-r0 do_configure: QA Issue: mender-client: invalid PACKAGECONFIG: inventory-network-scripts [invalid-packageconfig]

```

Is it something that can be ignored for the moment?

---

<div class="post-metadata">

**Author:** ![valentin.m](https://avatars.discourse-cdn.com/v4/letter/v/c0e974/32.png) [@valentin.m](https://hub.mender.io/u/valentin.m)\
**Post date:** [December 26, 2020, 7:17pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/12 "2020-12-26T19:17:57Z")

</div>

Hello,

seems like I’m having almost similar problems: [Intel-uefiimg is not bootable](https://hub.mender.io/t/intel-uefiimg-is-not-bootable/3026)

However, I just checked and in my case, `mender_kernel_root_base` is correctly set according to my settings from local.conf - maybe this is not the root cause for those issues.

Did you find any other reasons so far?

Best,  
Valentin

---

<div class="post-metadata">

**Author:** ![veikkaus](https://avatars.discourse-cdn.com/v4/letter/v/a3d4f5/32.png) [@veikkaus](https://hub.mender.io/u/veikkaus)\
**Post date:** [January 13, 2021, 9:36pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/13 "2021-01-13T21:36:46Z")

</div>

Same setup, same problem.

JJ

---

<div class="post-metadata">

**Author:** ![johny](https://avatars.discourse-cdn.com/v4/letter/j/779978/32.png) [@johny](https://hub.mender.io/u/johny)\
**Post date:** [January 14, 2021, 2:15pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/14 "2021-01-14T14:15:52Z")

</div>

I resolved the problem but the project is not in front of me at the moment and cannot tell you exactly what was the issue. However, I remember it was related to the `INITRAMFS_IMAGE`. There were some issues with the `WKS` - **systemd** was enabled. Hope this can help!

---

<div class="post-metadata">

**Author:** ![deffo](https://avatars.discourse-cdn.com/v4/letter/d/ec9cab/32.png) [@deffo](https://hub.mender.io/u/deffo)\
**Post date:** [March 3, 2021, 8:50am UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/15 "2021-03-03T08:50:31Z")

</div>

We’re seeing this too on an UP Squared board. Could you please have a look at this, @kacf @mirzak. Setup was working correct on warrior, on dunfell, we’re seeing “Reboot Into Firmware Interface” which apparently comes from systemd-boot source code [1]. The EFI Partition has changed, both the binaries aswell as the grub.cfg [2]. Also interesting is the partition setup on the USB drives I tested. First one with the GPT PMBR mismatch is dunfell, second one is the warrior setup, which works:

```
Disk /dev/sdf: 7.54 GiB, 8095006720 bytes, 15810560 sectors
Disk model:
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A38FA7D5-FA5A-40C4-BC23-7747F9DC9C0F

Device Start End Sectors Size Type
/dev/sdf1 16384 278527 262144 128M EFI System
/dev/sdf2 278528 4194303 3915776 1.9G Linux filesystem
/dev/sdf3 4194304 8110079 3915776 1.9G Linux filesystem
/dev/sdf4 8110080 10207231 2097152 1G Linux filesystem
GPT PMBR size mismatch (8191999 != 15495167) will be corrected by write.
The backup GPT table is not on the end of the device.

Disk /dev/sdg: 7.39 GiB, 7933526016 bytes, 15495168 sectors
Disk model: DT 101 G2
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A1667EDA-FC94-4ECC-9ED3-CCCD4610D524

Device Start End Sectors Size Type
/dev/sdg1 16384 49151 32768 16M EFI System
/dev/sdg2 49152 3981311 3932160 1.9G Linux filesystem
/dev/sdg3 3981312 7913471 3932160 1.9G Linux filesystem
/dev/sdg4 7913472 8175615 262144 128M Linux filesystem

```

[1] [systemd/boot.c at main · systemd/systemd · GitHub](https://github.com/systemd/systemd/blob/main/src/boot/efi/boot.c#L2366)  
[2] [History for 90\_mender\_boot\_grub.cfg - mendersoftware/grub-mender-grubenv · GitHub](https://github.com/mendersoftware/grub-mender-grubenv/commits/master/90_mender_boot_grub.cfg)

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [March 4, 2021, 7:48am UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/16 "2021-03-04T07:48:32Z")

</div>

Hmm, it’s hard to know which end to start here. Is `EFI_PROVIDER` indeed set to `grub-efi`?

```auto
bitbake -e core-image-minimal | grep EFI_PROVIDER=

```

Also can you check the file layout on the boot partition by mounting it and calling:

```auto
find <MOUNTPOINT>

```

---

<div class="post-metadata">

**Author:** ![deffo](https://avatars.discourse-cdn.com/v4/letter/d/ec9cab/32.png) [@deffo](https://hub.mender.io/u/deffo)\
**Post date:** [March 4, 2021, 8:37am UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/17 "2021-03-04T08:37:16Z")

</div>

Apparently the EFI\_PROVIDER has changed from warrior to dunfell. On warrior it was:

EFI\_PROVIDER=“grub-efi”  
EFI\_PROVIDER\_mender-grub=“grub-efi”  
EFI\_PROVIDER\_x86-x32=“grub-efi”

MENDER\_STORAGE\_DEVICE="/dev/sda"  
MENDER\_STORAGE\_DEVICE\_BASE="/dev/sda"  
MENDER\_STORAGE\_DEVICE\_BASE\_DEFAULT="/dev/sda"  
MENDER\_STORAGE\_DEVICE\_BASE\_DEFAULT\_mender-ubi="/dev/sda\_"  
MENDER\_STORAGE\_DEVICE\_DEFAULT="/dev/mmcblk0"  
MENDER\_STORAGE\_DEVICE\_DEFAULT\_mender-ubi=“ubi0”

On dunfell it’s:

EFI\_PROVIDER=“systemd-boot”  
EFI\_PROVIDER\_x86-x32=“grub-efi”  
\_MENDER\_EFI\_PROVIDER\_DEFAULT=“grub-efi”  
\_MENDER\_EFI\_PROVIDER\_DEFAULT\_mender-grub=“grub-efi”  
\_MENDER\_EFI\_PROVIDER\_DEFAULT\_mender-grub\_mender-bios=""

MENDER\_STORAGE\_DEVICE="/dev/sda"  
MENDER\_STORAGE\_DEVICE\_BASE="/dev/sda"  
MENDER\_STORAGE\_DEVICE\_BASE\_DEFAULT="/dev/sda"  
MENDER\_STORAGE\_DEVICE\_BASE\_DEFAULT\_mender-ubi="/dev/sda\_"  
MENDER\_STORAGE\_DEVICE\_DEFAULT="/dev/mmcblk0"  
MENDER\_STORAGE\_DEVICE\_DEFAULT\_mender-ubi=“ubi0”

Which makes sense, as the boot menu which is shown is the one from systemd-boot. I don’t know who changed it, mender, systemd or intel? Will find out.

Here you can see the diff between the warrior EFI partition on the left and the dunfell EFI partition on the right:

 ![2](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/2X/1/1fc72424be14b5a5db681517cc55d057a5b92b57.jpeg)

grub.cfg has changed as well, that was a change introduced by you guys I guess:

 ![1](https://canada1.discourse-cdn.com/flex036/uploads/mender/original/2X/c/c7b3bf16257e3733861df8969fcb0d633eca0df8.jpeg)

Tried the old grub.cfg, same error though.

Best regards

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [March 4, 2021, 9:52am UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/18 "2021-03-04T09:52:58Z")

</div>

Yes, I don’t think `grub.cfg` is the culprit here.

`EFI_PROVIDER=“systemd-boot”` is quite clearly wrong. Maybe the Mender assignment type is too weak. Can you post the output of:

```auto
bitbake -e core-image-minimal | grep -B100 EFI_PROVIDER=

```

---

<div class="post-metadata">

**Author:** ![deffo](https://avatars.discourse-cdn.com/v4/letter/d/ec9cab/32.png) [@deffo](https://hub.mender.io/u/deffo)\
**Post date:** [March 4, 2021, 11:08am UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/19 "2021-03-04T11:08:45Z")

</div>

That was indeed the reason for the wrong behaviour. When I set

`EFI_PROVIDER="grub-efi"`

in local.conf, it boots. So apparently meta-intel overwrites the settings in meta-mender:

```
meta-mender/meta-mender-core/classes/mender-setup-grub.inc:14:EFI_PROVIDER ?= "${_MENDER_EFI_PROVIDER_DEFAULT}"
meta-mender/meta-mender-core/classes/mender-setup-grub.inc:15:_MENDER_EFI_PROVIDER_DEFAULT = ""
meta-mender/meta-mender-core/classes/mender-setup-grub.inc:16:_MENDER_EFI_PROVIDER_DEFAULT_mender-grub = "grub-efi"
meta-mender/meta-mender-core/classes/mender-setup-grub.inc:17:_MENDER_EFI_PROVIDER_DEFAULT_mender-grub_mender-bios = ""
meta-intel/conf/machine/include/meta-intel.inc:44:EFI_PROVIDER ?= "systemd-boot"
meta-intel/conf/machine/include/meta-intel.inc:45:EFI_PROVIDER_x86-x32 = "grub-efi"
```

---

<div class="post-metadata">

**Author:** ![kacf](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/kacf/32/146_2.png) [@kacf](https://hub.mender.io/u/kacf)\
**Post date:** [March 4, 2021, 12:26pm UTC](https://hub.mender.io/t/simple-configuration-dunfell/2991/20 "2021-03-04T12:26:04Z")

</div>

So order might matter here. I’m guess that meta-mender is listed before meta-intel? Does swapping the order fix the problem?

[Next page](https://hub.mender.io/t/simple-configuration-dunfell/2991.md?page=2)
