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.
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?
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:
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.
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
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:
