Problem: conflicting requests - nothing provides kernel-devicetree needed by packagegroup

Board Integrations Yocto Project
,
1

Board description

Hey, I’m new to Yocto and I’m having a problem with the “mender-full” implementation. Here’s my configuration below, which is my KAS .yml file:

header:
version: 11

repos:
poky:
url: "https://git.yoctoproject.org/poky.git"
refspec: "scarthgap"
layers:
meta:
meta-poky:
meta-yocto-bsp:

meta-openembedded:
url: "https://git.openembedded.org/meta-openembedded"
refspec: "scarthgap"
layers:
meta-oe:
meta-networking:
meta-python:

meta-mender:
url: "https://github.com/mendersoftware/meta-mender.git"
refspec: "scarthgap"
layers:
meta-mender-core:

build_system: oe

target:
- u-boot
- core-image-minimal

machine: genericarm64

distro: poky


local_conf_header:
my-config: |

INHERIT += "mender-full"
INIT_MANAGER = "systemd"

I removed a lot of things from my local_conf_header section to isolate the problem!

Test results

ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command '/workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/etc/yum.repos.d --installroot=/workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs --setopt=logdir=/workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp --repofrompath=oe-repo,/workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/oe-rootfs-repo --nogpgcheck install mender-auth mender-update packagegroup-core-boot run-postinsts' returned 1:
DNF version: 4.19.0
cachedir: /workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/rootfs/var/cache/dnf
Added oe-repo repo from /workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/oe-rootfs-repo
User-Agent: falling back to 'libdnf': could not detect OS or basearch
repo: using cache for: oe-repo
oe-repo: using metadata from Mon 29 Sep 2025 08:14:16 AM UTC.
--> Starting dependency resolution
--> Finished dependency resolution
Error: 
 Problem: conflicting requests
  - nothing provides kernel-devicetree needed by packagegroup-core-boot-1.0-r0.genericarm64 from oe-repo
(try to add '--skip-broken' to skip uninstallable packages)

ERROR: Logfile of failure stored in: /workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_rootfs.156121
ERROR: Task (/workdir/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 5643 tasks of which 5642 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
  /workdir/poky/meta/recipes-core/images/core-image-minimal.bb:do_rootfs
    log: /workdir/build/tmp/work/genericarm64-poky-linux/core-image-minimal/1.0/temp/log.do_rootfs.156121
Summary: There was 1 ERROR message, returning a non-zero exit code.
2025-09-29 08:36:27 - ERROR    - Command returned non-zero exit status 1

In case this is useful I am working on the scathgap branch.

Question

The error: “nothing provides kernel-devicetree needed by packagegroup-core-boot-1.0-r0.genericarm64 from oe-repo” comes from the fact that kernel-devicetree is not generated or available in the build packages for the genericarm64 machine, even though it is expected as an essential dependency for booting in Yocto and Mender.

However, I’m on a genericarm64 machine because the company doesn’t yet know which processor to choose; the only thing I know is that it will be on an arm64-type processor. The problem is that I don’t know how the devicetree works in my case, whether one is generated anyway, or if I’m at a dead end…

Thank you in advance for your valuable help.

2

Hi @Stan,

Thanks for reaching out! I did a bit of testing and research, and here’s my findings:

  • In the case of arm, there usually is no built-in UEFI provider. Thats why in the mender-setup-grub.inc class, u-boot is selected as the provider for arm and arm64
  • by default, Mender expects u-boot to load the device tree from the resulting root filesystem. Thats why it usually needs to be installed, and is in the dependency chain.
  • therefore u-boot, and the kernel-devicetree are expected to build and install.

For your specific case, did you choose genericarm64 for a particular reason? As you say you don’t have actual hardware yet, I guess you are running mostly in emulation anyways. In that case, you could just switch to qemuarm64. This one should be working right out of the box, and you switch to the target hardware once known.

If you want to stick with genericarm64, then a bit of work will be needed to first make your build aware of being able to succeed without the device tree, adapting the loading scripts, and correctly passing the firmware/UEFI provided device tree to the kernel. This might be interesting, but probably not trivial.

Greetz,
Josef

3

Hi Josef,

Thank you for your detailed response! Indeed, I switched to qemuarm64 and managed to resolve the issue by retrieving the default device tree using the following command:

runqemu qemuarm64 qemuparams="-machine virt,dumpdtb=qemu.dtb"

I appreciate your guidance — it definitely helped clarify the path forward.

Best regards,
Stan