Simple configuration (dunfell)

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.

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!

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

Things that are covered here,

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.

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.

Looks good,

And which image do you use to provision the device?

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"

Sorry, didn’t get it. .uefiimg.

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

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?

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

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.

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?

Hello,

seems like I’m having almost similar problems: Intel-uefiimg is not bootable

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

Same setup, same problem.

JJ

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!

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
[2] History for 90_mender_boot_grub.cfg - mendersoftware/grub-mender-grubenv · GitHub

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

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

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

find <MOUNTPOINT>

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:

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

Tried the old grub.cfg, same error though.

Best regards

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:

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

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"
1 Like

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