yocto@lists.yoctoproject.org

Switching between multiple DISTROs without "contamination"

Nicolas Jeker

#57508

Hi all,

I'm currently using an additional layer and image to differentiate
between a release and development build (enabling NFS, SSH, root login,
etc.). To create a development build, I manually add the layer to
bblayers.conf. This works quite well, but feels a bit clumsy to
integrate into a CI/CD pipeline.

Per these past discussions here [1][2], I'm now trying to migrate to
multiple DISTROs, something like "mydistro" and "mydistro-dev".

While migrating some of the changes, I discovered that I run into
caching(?) issues. I have a recipe for an internal application and want
to include additional systemd service files in the development image.

What I did was this:

Added "application-dbg.service" to recipes-internal/application/files

Adapted application.bb recipe:

SRC_URI:append:mydistro-dev = " file://application-dbg.service"

do_install {
    # ...snip...
    # systemd service
    install -d ${D}${systemd_system_unitdir}
    install -m 0644 ${WORKDIR}/application.service
${D}${systemd_system_unitdir}
}

do_install:append:mydistro-dev() {
    # debug systemd services
    install -d ${D}${systemd_system_unitdir}
    install -m 0644 ${WORKDIR}/application-dbg.service
${D}${systemd_system_unitdir}
}


When I run "DISTRO=mydistro-dev bitbake application" followed by
"DISTRO=mydistro bitbake application", the debug service file is still
present in the package. This seems to be caused by the "image"
directory in the recipe WORKDIR not being cleaned between subsequent
do_install runs. Is this expected behaviour? What's the best solution?

Kind regards,
Nicolas

[1]:
https://lore.kernel.org/yocto/CAH9dsRiArf_9GgQS4hCg5=J_Jk6cd3eiGaOiQd788+iSLTuU+g@mail.gmail.com/
[2]:
https://lore.kernel.org/yocto/VI1PR0602MB3549F83AC93A53785DE48677D3FD9@VI1PR0602MB3549.eurprd06.prod.outlook.com/

Re: Customizing SERIAL_CONSOLES

chris yocto

#57507

Thank you for you reply.

I actually do want to replace SERIAL_CONSOLES because I am using the original for another purpose ( not a console).

Re: Customizing SERIAL_CONSOLES

Khem Raj

#57506

On Tue, Jul 12, 2022 at 12:41 PM chris yocto <chrisyocto2022@...> wrote:

Hi,

I’m trying to customize the SERIAL_CONSOLES variable. In another thread I read this can be done by adding a machine-extra.conf file too my custom layer. So I added “ SERIAL_CONSOLES = "115200;ttymxc0" ” to my machine-extra.conf, but when I  bitbake my custom image, no changes are found.

In the conf file from the bsp for the board I’m using I found “SERIAL_CONSOLES = "115200;ttymxc2", when I change this to SERIAL_CONSOLES ?= "115200;ttymxc2" my changes are being applied.

This off course is not ideal since I then still don’t have all changes in my own layer.

Is there a way I can solve this?
there can be multiple entries in SERIAL_CONSOLES so you might try
adding instead of replacing

 SERIAL_CONSOLES += "115200;ttymxc0"

might work

Kind regards,

Chris

Customizing SERIAL_CONSOLES

chris yocto

#57505

Hi,

I’m trying to customize the SERIAL_CONSOLES variable. In another thread I read this can be done by adding a machine-extra.conf file too my custom layer. So I added “ SERIAL_CONSOLES = "115200;ttymxc0" ” to my machine-extra.conf, but when I bitbake my custom image, no changes are found.

In the conf file from the bsp for the board I’m using I found “SERIAL_CONSOLES = "115200;ttymxc2", when I change this to SERIAL_CONSOLES ?= "115200;ttymxc2" my changes are being applied.

This off course is not ideal since I then still don’t have all changes in my own layer.

Is there a way I can solve this?

Kind regards,

Chris

[PATCH yocto-autobuilder-helper] config.json: Set SDKMACHINE to aarch64 for oe-selftest-armhost

Ross Burton

#57504

Although bitbake.conf sets the default SDKMACHINE to the build
architecture, config.json resets that to i686.

As oe-selftest assumes that the SDKs it builds are usable on the host
machine, we should set SDKMACHINE=3Daarch64 in the oe-selftest-armhost
build.

A follow-up more invasive patch to clean up the SDKMACHINE assignments
is in progress, once it has been verified to not cause regressions.

Signed-off-by: Ross Burton <ross.burton@...>
---
 config.json | 1 +
 1 file changed, 1 insertion(+)

diff --git a/config.json b/config.json
index 15adeb3..ce76056 100644
--- a/config.json
+++ b/config.json
@@ -881,6 +881,7 @@
             "TEMPLATE" : "selftest"
         },
         "oe-selftest-armhost" : {
+            "SDKMACHINE": "aarch64",
             "TEMPLATE" : "selftest"
         },
         "reproducible" : {
--=20
2.34.1

Sorry, a test

Ross Burton

#57503

Apologies for the test spam. Hopefully this doesn’t have a legal disclaimer attached.

Ross

Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>

#57502

On Mon, 11 Jul 2022 17:46 +0200, Gregory Anders wrote:
On Friday, July 08, 2022 08:12 AM MDT, Khem Raj <raj.khem@...> wrote:

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
Problem solved: the issue was actually that I was using a network
sstate cache,
and the cached output of gcc-cross did not contain gfortran.
Disabling the
sstate cache for gcc-cross causes gfortran to be included in the
sysroot and
now all is working as expected.You shouldn't have to disable the sstate cache but glad you got it
working. Which release series is that with?I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).
Perhaps it’s using locked sstate which might be the reasonI didn't know the sstate could be locked -- how would one unlock it? Could you
point me toward some relevant docs?

After some cursory searching the only thing I've found is the 'locked-sigs.inc'
file. And indeed, Petalinux does ship with a locked-sigs.inc file which
includes a signature for gcc-cross-arm. But adding gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES doesn't seem to have any effect.I think I've finally figured this out and just wanted to provide some
closure for posterity's sake.

My initial "solution" of clearing the SSTATE_MIRRORS variable was not
actually correct. It turns out I was not actually even clearing it
correctly, and when I "fixed" it to correctly clear the variable it
caused a build error.

The solution was, in fact, to add gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES. I simply added this line to my configuration:

    SIGGEN_UNLOCKED_RECIPES += "gcc-cross-arm gcc-runtime libgcc"

In my last message, I said that this had no effect. I can only guess
that it appeared that way because some other part of the build was being
cached. After clearing everything in the build directory and
re-building, it seems to work as expected.

Thanks to everyone who offered help.

Greg

Recipe fails at do_rm_work due to failed attempt to delete a named pipe (FIFO)

David Antliff

#57501

Hi,

I'm working with a PetaLinux 2021.2 project, which defines a recipe called "petalinux-initramfs-image".

# Simple petalinux initramfs image.
DESCRIPTION = "Small image capable of booting a device. The kernel includes \

the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \

first 'init' program more efficiently."

INITRAMFS_SCRIPTS ?= "initramfs-framework-base \

initramfs-module-e2fs \

initramfs-module-udhcpc \

initramfs-module-searche2fs \

"

INITRAMFS_SCRIPTS_append_k26 = " initramfs-module-exec"

INITRAMFS_PACKAGES ?= "${VIRTUAL-RUNTIME_base-utils} \

base-passwd \

e2fsprogs \

${ROOTFS_BOOTSTRAP_INSTALL} \

${MACHINE_ESSENTIAL_EXTRA_RDEPENDS} \

"

BAD_RECOMMENDATIONS += "initramfs-module-rootfs"

PACKAGE_INSTALL ?= "packagegroup-core-boot ${INITRAMFS_PACKAGES} ${INITRAMFS_SCRIPTS}"

# Do not pollute the initrd image with rootfs features

IMAGE_FEATURES = ""

export IMAGE_BASENAME = "petalinux-initramfs-image"

IMAGE_LINGUAS = ""

LICENSE = "MIT"

IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"

inherit core-image

IMAGE_ROOTFS_SIZE = "8192"

IMAGE_ROOTFS_EXTRA_SPACE = "0"

rm_work_rootfs[noexec] = "1"

rm_work_rootfs[cleandirs] = ""

RM_WORK_EXCLUDE_ITEMS = "rootfs"

For reasons I don't understand, this recipe fails to build at the do_rm_work task. Looking at the bitbake -v log, I can see that this recipe is somehow causing the temp directory in the build directory to be deleted:

+ rm -rf recipe-sysroot-native

+ for dir in *

+ '[' rootfs = pseudo ']'

+ echo rootfs

+ grep -q -w rootfs

+ for dir in *

+ '[' temp = pseudo ']'

+ echo rootfs

+ grep -q -w temp

+ rm -rf temp

+ ret=0

+ trap '' 0

+ exit 0

ERROR: petalinux-initramfs-image-1.0-r0 do_rm_work: [Errno 2] No such file or directory: '/[removed]/build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.59670'

I think whatever is calling do_rm_work (in rm_work.bbclass) is creating a named pipe (FIFO) file in the build/...petalinux-initramfs-image/1.0-r0/temp directory, for whatever purpose, and then when this recipe (for whatever reason) causes the deletion of the temp directory and exits, this outer entity then expects to be able to clean up the FIFO file it created, fails to do so, and raises the fatal error.

I'm assuming that this is a problem with the recipe itself, but I (with my limited knowledge and experience in this area) cannot see anything obvious in there that would lead to the inadvertent deletion of the temp directory.

Note that if I add RM_WORK_EXCLUDE += "petalinux-initramfs-image" then the build does not fail and I see this instead:

NOTE: Executing Tasks
+ do_rm_work

+ for p in petalinux-initramfs-image

NOTE: petalinux-initramfs-image-1.0-r0 do_rm_work: rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE

+ '[' petalinux-initramfs-image = petalinux-initramfs-image ']'

+ bbnote 'rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE'

+ '[' -p /[removed]/build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.60213 ']'

+ printf '%b\0' 'bbnote rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE'

+ exit 0

+ bb_bash_exit_handler 'exit 0'

+ ret=0

+ set +x

There the named pipe file is mentioned, but I'm not sure why a test for its existence is here, interleaved with output from rm_work.bbclass. I don't see that in rm_work.bbclass anywhere - or is it a part of bbnote?

Any idea what's going on with this recipe?

-- David.

M+ & H bugs with Milestone Movements WW2"All,

Stephen Jolley

#57500

All,

YP M+ or high bugs which moved to a new milestone in WW28 are listed below:

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
High	14065	Automated ptest regression testing	randy.macleod@...	ross.burton@...	4.1 M2	4.1 M3
Medium+	14775	AB-INT: SDK preparation failure: SState: cannot test file://[...] TimeoutError('timed out')	richard.purdie@...	unassigned@...	4.1 M2	4.1 M3

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Enhancements/Bugs closed WW28!

Stephen Jolley

#57499

All,

The below were the owners of enhancements or bugs closed during the last week!

Who	Count
alejandro@...	2
yogesh.tyagi@...	1
ptsneves@...	1
randy.macleod@...	1
ross.burton@...	1
Grand Total	6

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Current high bug count owners for Yocto Project 4.1

Stephen Jolley

#57498

All,

Below is the list as of top 35 bug owners as of the end of WW28 of who have open medium or higher bugs and enhancements against YP 4.1. There are 77 possible work days left until the final release candidates for YP 4.1 needs to be released.

Who	Count
michael.opdenacker@...	36
ross.burton@...	27
david.reyna@...	23
bruce.ashfield@...	21
randy.macleod@...	16
richard.purdie@...	10
saul.wold@...	10
JPEWhacker@...	9
sakib.sajal@...	9
Aryaman.Gupta@...	6
tim.orling@...	6
mhalstead@...	5
jon.mason@...	4
akuster808@...	3
tvgamblin@...	2
pavel@...	2
pgowda.cve@...	2
Qi.Chen@...	2
hongxu.jia@...	2
sundeep.kokkonda@...	2
mostthingsweb@...	1
aehs29@...	1
behanw@...	1
martin.beeger@...	1
Ahmed.Hossam@...	1
nicolas.dechesne@...	1
raj.khem@...	1
Martin.Jansa@...	1
thomas.perrot@...	1
shachar@...	1
ola.x.nilsson@...	1
alexandre.belloni@...	1
luca.ceresoli@...	1
alejandro@...	1
open.source@...	1
Grand Total	212

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley

#57497

All,

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 410 unassigned or newcomer bugs.

We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “4.1”, “4.2”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

* Email: sjolley.yp.pm@...

missing cgroups when trying to re-mount rootfs from initramfs busybox image

Embedded 1

#57496

I have busybox with an initramfs. When I try to re-mount the rootfs I
see this. This is with Yocto. Do I need to include systemd in my
initramfs image?

sh-5.0# exec switch_root /root /sbin/init
switch_root: failed to mount moving /run to /root/run: Invalid argument
switch_root: forcing unmount of /run
[  339.929584] systemd[1]: System time before build time, advancing clock.
[  339.974784] systemd[1]: Module 'autofs4' is built in
[  339.980811] systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file
 or directory
[  339.989411] systemd[1]: Failed to mount cgroup at /sys/fs/cgroup/systemd: No
such file or directory
[!!!!!!] Failed to mount API filesystems.
[  340.024657] systemd[1]: Freezing execution.

Re: Installing gfortran into native sysroot for libgfortran

Philip Balister

#57495

In my notes:

cat /dev/null > conf/locked-signs.inc

Philip

Show quoted text

On 7/11/22 12:49, Gregory Anders wrote:
On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:
  
On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto:greg@...>> wrote:

     On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
      >On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
      >> Problem solved: the issue was actually that I was using a network
      >> sstate cache,
      >> and the cached output of gcc-cross did not contain gfortran.
      >> Disabling the
      >> sstate cache for gcc-cross causes gfortran to be included in the
      >> sysroot and
      >> now all is working as expected.
      >
      >You shouldn't have to disable the sstate cache but glad you got it
      >working. Which release series is that with?

     I am using Xilinx's Petalinux tool, which uses honister under the
     hood. Xilinx maintains an sstate cache for Petalinux, which is quite
     convenient for cutting down build times, but apparently setting the
     FORTRAN variable does not invalidate the sstate cache entry for the
     gcc-cross recipe (which it should, as it affects the build outputs).


Perhaps it’s using locked sstate which might be the reasonIt is. It was great fun to find the path to disable it when I also had
this issue :)

Philip(Apologies for the double post to the list.)
Philip, would you mind sharing what you did to disable it?
Thanks,
Greg

Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>

#57494

On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:

On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto:greg@...>> wrote:

    On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
     >On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
     >> Problem solved: the issue was actually that I was using a network
     >> sstate cache,
     >> and the cached output of gcc-cross did not contain gfortran.
     >> Disabling the
     >> sstate cache for gcc-cross causes gfortran to be included in the
     >> sysroot and
     >> now all is working as expected.
     >
     >You shouldn't have to disable the sstate cache but glad you got it
     >working. Which release series is that with?

    I am using Xilinx's Petalinux tool, which uses honister under the
    hood. Xilinx maintains an sstate cache for Petalinux, which is quite
    convenient for cutting down build times, but apparently setting the
    FORTRAN variable does not invalidate the sstate cache entry for the
    gcc-cross recipe (which it should, as it affects the build outputs).


Perhaps it’s using locked sstate which might be the reasonIt is. It was great fun to find the path to disable it when I also had
this issue :)

Philip(Apologies for the double post to the list.)

Philip, would you mind sharing what you did to disable it?

Thanks,

Greg

How to get license text

William Huang

#57493

Hi,
I was wondering if it is possible to get the license information for all of the deployed packages in the image? I know there's a license.manifest file in deploy/licenses, but I'm looking for a file that includes that manifest as well as the paragraph associated with the license. Closest I found was in the /usr/share/common-license folder which has the LICENSE or COPYING file for each package, but I am looking if there's a single file that contains this information instead.

Thanks

Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>

#57492

On Friday, July 08, 2022 08:12 AM MDT, Khem Raj <raj.khem@...> wrote:

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
Problem solved: the issue was actually that I was using a network
sstate cache,
and the cached output of gcc-cross did not contain gfortran.
Disabling the
sstate cache for gcc-cross causes gfortran to be included in the
sysroot and
now all is working as expected.You shouldn't have to disable the sstate cache but glad you got it
working. Which release series is that with?I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).
Perhaps it’s using locked sstate which might be the reasonI didn't know the sstate could be locked -- how would one unlock it? Could you
point me toward some relevant docs?

After some cursory searching the only thing I've found is the 'locked-sigs.inc'
file. And indeed, Petalinux does ship with a locked-sigs.inc file which
includes a signature for gcc-cross-arm. But adding gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES doesn't seem to have any effect.

ALTERNATIVE and RDEPENDS

Konrad Weihmann <kweihmann@...>

#57491

Hi all,

is there a way to set the package metadata in a way that it would require one of the packages providing a tool via the ALTERNATIVE_ mechanism?

E.g. sed for instance could be provided by busybox (if enabled in config) or by the standalone sed recipe - within my recipe I would just want to make sure that any of the providing packages is available/used when assembling the image.

This basically affects all of the tools that are provided by coreutils and busybox too

I would be happy about any pointer...

Regards
Konrad

Re: source-less python

Aurum Nitrogen

#57490

Hi,

So after a little bit of research, I've implemented this feature in poky.

The way buildroot works, is that it doesn't create any .pyc files during the build process of single packages but has a post rootfs hook that (If that's what the user has configured) compiles the .py files into .pyc files and removes the .py files.

The compilation to .pyc files is done using a small script that uses python's py_compile module.

I have attached the diff to poky for implementation of this feature and the pycompile.py script.

I would love to get your input on this.

Another thing I noticed while doing this research was that the python recipe has a variable called INCLUDE_PYCS that decides if to include the .pyc files in the package. This is nice but why not implement this in the rest of the python package recipes? It can be added to setuptools3.bbclass or something like that. What do you think?

Thanks a lot,

John

‫בתאריך יום ה׳, 23 ביוני 2022 ב-19:10 מאת ‪Ross Burton‬‏ <‪Ross.Burton@...‬‏>:‬

Show quoted text

On 23 Jun 2022, at 23:40, Aurum Nitrogen via lists.yoctoproject.org <aurumnitrogen=gmail.com@...> wrote:
>
> Hi,
> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
> I know that in buildroot it is supported.
> Was this discussed and decided against? Is this an open issue?

There’s an open issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434

The easiest implementation would be a rootfs-time postprocessing step where you compile every .py file, and then delete the .py. Is this what buildroot does?

This does break feeds, but the alternative (of changing how packaging is done) would be a lot more invasive.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

pycompile.py

diff.patch

Re: meta-riscv layer *seems* to have broken opensbi_%.bbappend file

Khem Raj

#57489

On Sun, Jul 10, 2022 at 7:56 AM Robert P. J. Day <rpjday@...> wrote:

the SRC_URI line:

SRC_URI:append:nezha = " \ ...

seems odd since the machine name is actually "nezha-allwinner-d1", not
just "nezha". i checked and the two listed patches there don't appear
to be applied, for what i assume is just that reason.

This is a bug and this should be fixed to use full machine name for override since we do not have nezha SoC override

or is this somehow related to the "nezha.yml" file in the meta-riscv
layer?

No it’s unrelated

rday