# Problem: conflicting requests - nothing provides kernel-devicetree needed by packagegroup
**URL:** https://hub.mender.io/t/problem-conflicting-requests-nothing-provides-kernel-devicetree-needed-by-packagegroup/8025
**Category:** Yocto Project
**Tags:** yocto, mender-client
**Created:** [September 29, 2025, 8:55am UTC](https://hub.mender.io/t/problem-conflicting-requests-nothing-provides-kernel-devicetree-needed-by-packagegroup/8025 "2025-09-29T08:55:00Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@Stan](https://hub.mender.io/u/Stan)
#### Post date: [September 29, 2025, 8:55am UTC](https://hub.mender.io/t/problem-conflicting-requests-nothing-provides-kernel-devicetree-needed-by-packagegroup/8025/1 "2025-09-29T08:55:00Z")
# 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:
```yml
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
```bash
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.
---
### Author:  [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)
#### Post date: [September 30, 2025, 8:08am UTC](https://hub.mender.io/t/problem-conflicting-requests-nothing-provides-kernel-devicetree-needed-by-packagegroup/8025/2 "2025-09-30T08:08:05Z")
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
---
### Author:  [@Stan](https://hub.mender.io/u/Stan)
#### Post date: [September 30, 2025, 8:21am UTC](https://hub.mender.io/t/problem-conflicting-requests-nothing-provides-kernel-devicetree-needed-by-packagegroup/8025/3 "2025-09-30T08:21:46Z")
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:
```bash
runqemu qemuarm64 qemuparams="-machine virt,dumpdtb=qemu.dtb"
```
I appreciate your guidance — it definitely helped clarify the path forward.
Best regards,
Stan