Hi,
I’ve got mender working with grub on intel-corei7-64 (scarthgap 5.0.16). As it’s a commercial product, I’m trying to replace grub with u-boot due to gplv3.
I’ve created a few u-boot build attempts, but don’t have it working yet. I’m new to UEFI so hoping for some guidance/direction.
My builds are currently using mender-full.yml. With the mender-grub based build, I’ve mounted the .bootimg on my dev PC and it shows:
This works on the device. For u-boot try #1, I replaced mender-grub with mender-u-boot. This builds and creates a uefiimg, but UEFI on the device doesn’t see anything. So I mounted .bootimg on my PC and it just shows:
I then tried to set EFI_PROVIDER to “u-boot”, results were the same. I do have UBOOT_MACHINE set to “efi-x86_app64_defconfig”. So the u-boot workdir has both u-boot.bin and u-boot-app.efi. Do I need to explicitly add one to IMS_BOOT_FILES?
For uboot try #2, I followed the steps here: Explicit WKS Partitioning for Mender A/B Updates
Is that the direction I need to go in? I’ve got a build with a wks file with uboot.env in 1st partition, and then the 2nd partition setup for --source bootimg-partition, but I’m not sure what files/structure I should add to the bootimg.
The device has a SATA SSD drive.
Thanks, Daryl
Ok, I’ve got u-boot working as an EFI payload. I used the Explicit WKS Partitioning approach. The u-boot environment is stored in ESP and /etc/fw_env.config points to it.
# Configuration file for fw_printenv/fw_setenv
# Device name Offset Size Erase block size Number of erase blocks
# For FAT-based environment storage, we need to specify the files
# Primary environment file
/uboot/uboot.env 0x0 0x20000
# Redundant environment file
And the u-boot environment is mounted to /uboot and the environment files are there. And I can view them with fw_printenv.
However, mender-update show-artifact returns unknown. I’m using the mender-explicit-wic.bbclass from the demo layer, only change is how WKS_FILE gets set.
The kernel comes up, and the /data/mender folder is present. However, there aren’t any mender.conf or device-type files. Those are in /var/lib/mender -
root@ims-linux-default:/var/lib/mender# ll /var/lib/mender
total 32K
drwxr-xr-x 2 root root 4.0K Mar 31 12:09 ./
drwxr-xr-x 12 root root 4.0K Mar 31 12:03 ../
-r--r--r-- 1 root root 35 Mar 9 2018 device_type
-rw------- 1 root root 12K Mar 31 12:09 mender-store
-rw------- 1 root root 8.0K Mar 31 12:09 mender-store-lock
-rw------- 1 root root 66 Mar 9 2018 mender.conf
For my previous working image with grub, there’s a link in /var/lib/mender pointing to /data/mender. I can fix that, but mender-update -h shows default datastore path is /var/lib/mender so I’d imagine it sees them. And the data in the files looks correct.
device_type=intel-corei7-64-custom
{
"RootfsPartA": "/dev/sda2",
"RootfsPartB": "/dev/sda3"
}
Any thoughts on what to try? Looking in mender-dataimg.bbclass I see it using mender-bootstrap-artifact. Do I need that with this approach?
Hi @dnebrich,
Nice, yeah that’s a possible use case for the explicit wks approach: you can create advanced integrations while avoiding the intricacies of the mender-grub and mender-uboot features.
For the “unknown” software at the beginning, you’re right, you need to look into the mender-bootstrap-artifact. The probably best example to base your integration off is meta-mender/meta-mender-core/classes/mender-dataimg.bbclass at master · mendersoftware/meta-mender · GitHub
Did you need complex integration logic, or was it mostly a case of properly crafting the wks?
Greetz,
Josef
Hi @TheYoctoJester
Thanks for response. I just added code to mender-explicit-wic.bbclass to create the link and install the artifact. Showing below in case it helps someone else.
# Add mender symlink to rootfs during rootfs creation
ROOTFS_POSTPROCESS_COMMAND += "create_mender_symlink; "
create_mender_symlink() {
# Create symlink /var/lib/mender
bbnote "Creating /var/lib/mender -> /data/mender symlink"
# Remove existing /var/lib/mender directory if it exists
if [ -d "${IMAGE_ROOTFS}${localstatedir}/lib/mender" ]; then
bbnote "Removing existing /var/lib/mender directory"
rm -rf ${IMAGE_ROOTFS}${localstatedir}/lib/mender
fi
install -d ${IMAGE_ROOTFS}${localstatedir}/lib
ln -sf /data/mender ${IMAGE_ROOTFS}${localstatedir}/lib/mender
install -d ${IMAGE_ROOTFS}/data/mender
}
# Install bootstrap artifact directly into the rootfs after it's created
install_bootstrap_to_rootfs() {
if [ -e "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.bootstrap-artifact" ]; then
bbnote "Installing bootstrap.mender to rootfs /data/mender/"
install -d ${IMAGE_ROOTFS}/data/mender
install -m 0400 "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.bootstrap-artifact" \
"${IMAGE_ROOTFS}/data/mender/bootstrap.mender"
bbnote "Bootstrap artifact installed successfully"
else
bbwarn "Bootstrap artifact not found at ${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.bootstrap-artifact"
bbwarn "This may cause 'mender show-artifact' to return 'unknown' on first boot"
bbwarn "Available files in IMGDEPLOYDIR:"
ls -la "${IMGDEPLOYDIR}/" | grep -E "(bootstrap|mender)" || bbwarn "No bootstrap/mender files found"
fi
}
# Install bootstrap artifact after bootstrap-artifact image is created but before WIC
do_image_wic[prefuncs] += "install_bootstrap_to_rootfs"
# Ensure bootstrap artifact is available before WIC processing
do_image_wic[depends] += "${PN}:do_image_bootstrap_artifact"
On first startup, bootstrap.mender is in /data/mender and the first time I ran mender-update show-artifact gives -
record_id=1 severity=info time="2026-Mar-31 16:53:00.340639" name="Global" msg="Installing the bootstrap Artifact"
local_2026-03-31_16:38:45
A few seconds later the expected MENDER_ARTIFACT_NAME was displayed. I’ll try updates next.
Honestly, I may not have needed to take this approach. When I first tried using mender-uboot, I wasn’t familiar with the UEFI shell and the ESP folder structure. Perhaps I could have just patched u-boot config and set the various MENDER_UBOOT_ options. I first tried EFI app, but had to switch to EFI payload. Not sure if the wks I ended up with requires this approach, but below is what I have.
And now that it’s working, I don’t want to change it. 
# EFI boot partition
part /boot/efi --source bootimg-partition --label boot --ondisk "sda" --align 8192 --fixed-size 16 --active --part-type C12A7328-F81F-11D2-BA4B-00A0C93EC93B
# Root filesystem A (active)
part --source rawcopy --sourceparams="file=.../file.ext4" --ondisk "sda" --align 8192 --fixed-size 3000000k --part-type 0FC63DAF-8483-4772-8E79-3D69D8477DE4
# Root filesystem B (not active)
part --ondisk "sda" --fstype=ext4 --align 8192 --fixed-size 3000000k --part-type 0FC63DAF-8483-4772-8E79-3D69D8477DE4
# Data partition
part /data --source rootfs --label data --fstype=ext4 --align=8192 --fixed-size=1024 --change-directory=data --part-type 0FC63DAF-8483-4772-8E79-3D69D8477DE4
part --ondisk "sda" --size 1024 --align 8192 --label=more_data --fstype=ext4
bootloader --ptable gpt
Thanks,
Daryl
Hi @dnebrich,
Great, thanks for sharing! As you are about to try updates, there is a somewhat simplistic script available to run the integration checklist: meta-mender-community/meta-mender-validation/recipes-mender/bootloader-validation/bootloader-validation_0.1.bb at scarthgap · mendersoftware/meta-mender-community · GitHub
As you are using u-boot, the canonical way should be fine and exercised.
If I find time I’ll try to boil down the information into an example in meta-mender-community so it hopefully helps the next one just like the explicit-wks one did for you.
Greetz,
Josef
