Fetcher failure for URL: 'file://dropbear.default'. Unable to fetch URL from any source

I am trying to override the dropbear.default

The layer looks like this : meta/recipes-core/dropbear

├── dropbear │ ├── 0001-urandom-xauth-changes-to-options.h.patch │ ├── 0005-dropbear-enable-pam.patch │ ├── 0006-dropbear-configuration-file.patch │ ├── dropbear │ ├── dropbear.default │ ├── dropbear-disable-weak-ciphers.patch │ ├── dropbearkey.service │ ├── dropbear@.service │ ├── dropbear.socket │ └── init ├── dropbear_2020.81.bb ├── dropbear_%.bbappend ├── dropbear.inc └── files ├── 0007-patch1.patch └── 0008-patch2.patch └──$MACHINE folder name ├──dropbear.default -------> this one I want to use to replace the old one from the /dropbear/dropbear.default above

I created a dropbear_%.bbappend

and in that dropbear_%.bbappend file I have

FILESEXTRAPATHS_prepend_myfolder := "${THISDIR}/${PN}:${THISDIR}/${MACHINE}:${THISDIR}/files:" -----> this should be

${THISDIR}/${MACHINE}:${THISDIR}/files:"

Still I got the same error

Solution

It is pretty unusual to have a bbappend in the same directory as the bb recipe it'll append to, but whatever floats your boat :) In that case, this unusual scenario is actually part of the issue.

I'm unsure what _myfolder is representing in FILESEXTRAPATHS_prepend_myfolder? If myfolder is not part of the OVERRIDES variable (or other implicit values, such as class-target, virtclass-, etc..) then it'll not work. I'm pretty sure you should actually just strip it from FILESEXTRAPATHS_prepend. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-OVERRIDES

Considering the current directory layout, the FILESEXTRAPATHS_prepend in your bbappend will be expanded to:

./dropbear:./${MACHINE}:./files:

The paths that will be searched by Yocto for files in SRC_URI will be searched from leftmost to rightmost, c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-FILESPATH (it is not phrased clearly though IMO I can give you that).

So technically, you're telling Yocto to search within the dropbear directory for dropbear.default first and then ${MACHINE} directory and then files. Which is already what's used by the original recipe, so all in all, your bbappend is a no-op for files you want to override.

To fix this, either:

move your bbappend to another directory (and probably layer since I'm pretty sure you don't have the rights to commit and push to the layer where the original dropbear recipe is? Then the dropbear.default file will be taken from dropbear, ${MACHINE} or files directory at the same level as your bbappend. (and since the paths in FILESEXTRAPATHS (and FILESPATH) are absolute, it'll find the file you want),
remove ${THISDIR}/${PN} (which is ./dropbear) from your FILESEXTRAPATHS_prepend or put it after the directory in which you have placed the file you want to override,
put a subdirectory named after the machine (${MACHINE}) directly in ./dropbear since directories specified in FILESPATH (and thus, FILESEXTRAPATHS) are automatically extended with FILESOVERRIDES which contains the machine name. Basically, let's say FILESPATH is set to dirA:dirB, dirA/poky (if poky is your distro) will be searched first, then dirB/poky, then dirA/machine, dirB/machine, dirA and finally dirB. So by having a subdirectory named after your machine in ./dropbear it'll be searched before ./dropbear by Yocto automatically. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-FILESPATH

You can check which directories are searched and in which order by reading the log.do_fetch log file from ${WORKDIR}/temp, with ${WORKDIR} probably going to end with being something like tmp/work/<target_arch>/dropbear/2020.81-r0/.

You can check the values of variables and the history of how the values were built by running bitbake dropbear -e. Since it can output several millions of lines, you usually either pipe it to less or more, redirect it to a file or pipe it to grep -e "^VARTOCHECK=".