Distros can customize the location of OPKG data using OPKGLIBDIR. In
OE-Core commit 11f1956cf5d7 ("package_manager.py: define info_dir and
status_file when OPKGLIBDIR isn't the default"), a fix was applied to
correctly set the info_dir and status_file options relative to
OPKGLIBDIR.
However, as the commit message notes, the opkg.conf file deployed as
part of the opkg package must also be adjusted to correctly reflect the
changed location. Otherwise, opkg running inside the image cannot find
its data.
Fix this by also setting the info_dir and status_file options in
opkg.conf to the correct location relative to OPKGLIBDIR.
Fixes: 11f1956cf5d7 ("package_manager.py: define info_dir and status_file when OPKGLIBDIR isn't the default")
(From OE-Core rev: 38224b19bda2592705ef4274c28cb250d9e980dc)
Signed-off-by: Harald Seiler <hws@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit adb939ae3635de6e02208859fbf29cf0ed39f565)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the KERNEL_DEBUG_TIMESTAMPS is not working as expected
at rebuild. That is, even if we set it to "1", the kernel build time
is not changed. The problem could be reproduced by the following steps.
1. bitbake core-image-minimal; start image and check `uname -a` output.
2. set in local.conf: KERNEL_DEBUG_TIMESTAMPS = "1"
3. bitbake core-image-minimal; start image and check `uname -a` output.
It's expected that after enabling KERNEL_DEBUG_TIMESTAMPS, the kernel
build time will be set to current date. But it's not. This is because
the compile.h was not re-generated when do_compile task was re-executed.
In mkcompile_h, we have:
"""
# Only replace the real compile.h if the new one is different,
# in order to preserve the timestamp and avoid unnecessary
# recompilations.
# We don't consider the file changed if only the date/time changed,
# unless KBUILD_BUILD_TIMESTAMP was explicitly set (e.g. for
# reproducible builds with that value referring to a commit timestamp).
# A kernel config change will increase the generation number, thus
# causing compile.h to be updated (including date/time) due to the
# changed comment in the
# first line.
"""
It has made it very clear that it will not be re-generated unless
we have KBUILD_BUILD_TIMESTAMP set explicitly. So we set this variable
explicitly in do_compile to fix this issue.
(From OE-Core rev: e44f0cda8176186d42a752631810c1cb5f1971eb)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 1b68c2d2d385013a1c535ef81172494302a36d74)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 526bdd88ccd758204452579333ba188e29270bde the imageType loop in
kernel_do_deploy was changed to use KERNEL_IMAGETYPE_FOR_MAKE rather
than KERNEL_IMAGETYPES. This broke the special handling for fitImage
immediately below because KERNEL_IMAGETYPE_FOR_MAKE never contains
fitImage.
It has always been my understanding that KERNEL_IMAGETYPE_FOR_MAKE
controlled what was passed to make, but KERNEL_IMAGETYPE controlled what
was installed/deployed. When the two are different then it's the
responsibility of whoever set KERNEL_IMAGETYPE_FOR_MAKE to ensure that
whatever comes out of the kernel build system has been transformed in to
the requested form by the time of installation. This is what happens for
kernel.bbclass's own support for vmlinux.gz.
I think this means that for KERNEL_IMAGETYPE vmlinux.gz, kernel.bbclass
is responsible for generating vmlinux.gz.initramfs[1] so that
kernel_do_deploy can deploy it. This means that the change in
526bdd88ccd758204452579333ba188e29270bde can be reverted, fixing
KERNEL_IMAGETYPE = "fitImage".
In addition, it ought to be possible for recipes and other classes that
use kernel.bbclass to hook into this mechanism by setting
KERNEL_IMAGETYPE_FOR_MAKE and performing their own transformations.
do_bundle_initramfs calls kernel_do_compile and we don't want it to
transform vmlinux to vmlinux.gz at that point, since it will fight
against the careful renaming and preserving that do_bundle_initramfs
does. Let's separate the transformation out of kernel_do_compile to a
new do_transform_kernel task that can be run at the right time. This
means that it's also logical to perform the equivalent translation for
the kernel with the initramfs in a separate
do_transform_bundled_initramfs task too.
This leaves two clear customisation points for recipes and other classes
to hook into the process and perform their transformations:
do_transform_kernel and do_transform_bundled_initramfs.
(I care about this because our recipes that use kernel.bbclass also set
KERNEL_IMAGETYPE_FOR_MAKE and transform vmlinux into a form suitable for
our bootloader after do_compile and do_bundle_initramfs into the format
matching KERNEL_IMAGETYPE. I'm unable to successfully bundle an
initramfs after 526bdd88ccd758204452579333ba188e29270bde, but I didn't
want to just revert that change to reintroduce the bug that it was
fixing.)
I can't say that I'm entirely happy with this change, but I'm unsure
what to do to improve it. I find the way that both the bare kernel and
the one with the initramfs both get deployed to be confusing, and a
waste of build time. I would like to not actually generate a publishable
kernel image at all during do_compile when an initramfs is in use, but I
suspect that this would affect valid use cases that I'm not aware of.
(From OE-Core rev: d9e9653616638f2b187d5e04540071ac34d99f56)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
[1] It could be argued that this should be vmlinux.initramfs.gz, but
that would require another special case in kernel_do_deploy and the
filename is only visible within this class and the recipes that use it
anyway.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 10a4a132e87e835726bf5da81a60f6f509b90765)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, when shortening sstate filenames, the reserved
characters for .siginfo were not considered, when siginfo=False,
resulting in differently shortend filenames for the sstate and siginfo
files. With this change, the filenames of the truncated sstate and
siginfo files have the same basename, just as is already the case for
untruncated filenames.
Making sure that the .siginfo files always have the filename of the
corresponding sstate file plus its .siginfo suffix, also when being
truncated, makes it easier to manage the sstate cache and an sstate
mirror outside of Bitbake/Yocto.
(From OE-Core rev: 408bf1b4bb4f4ed126c17fb3676f9fa0513065ba)
Signed-off-by: Manuel Leonhardt <mleonhardt@arri.de>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c2e0e43b7123cf5149833e0072c8edaea3629112)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CVE is in the io/fs package, which first appeared in go1.16.
Since dunfell is using go1.14, this issue does not apply.
CVE was fixed in fa2d41d0ca736f3ad6b200b2a4e134364e9acc59
Original code in b64202bc29b9c1cf0118878d1c0acc9cdb2308f6
(From OE-Core rev: 1e258940e9a6fabda6e7e60841082c113fdf9500)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only affects Windows platform, as per the release announcement [1]:
"If, on Windows, Cmd.Run, cmd.Start, cmd.Output, or cmd.CombinedOutput
are executed when Cmd.Path is unset and, in the working directory, there
are binaries named either "..com" or "..exe", they will be executed."
[1] https://groups.google.com/g/golang-announce/c/TzIC9-t8Ytg/m/IWz5T6x7AAAJ
(From OE-Core rev: 54c40730bc54aa2b2c12b37decbcc99bbcafd07a)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Dunfell uses golang 1.14 which does not contain the affected code (it
was introduced in golang 1.16). From the golang announcement [1]
"Reader.Open (the API implementing io/fs.FS introduced in Go 1.16) can
be made to panic by an attacker providing either a crafted ZIP archive
containing completely invalid names or an empty filename argument.
[1] https://groups.google.com/g/golang-announce/c/0fM21h43arc
(From OE-Core rev: 2329902f994b631d6b77e8bd501d5599db6d5306)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a bug in golang.org/x/net/html/parse.go. The golang compiler
includes a partial copy of this under src/vendor/golang.org/x/net/
however the "html" subdirectory is not included. So this bug does not
apply to the compiler itself.
(From OE-Core rev: b8a851faef9990ccb41ded875fc79cf28abd4a4e)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An off-by-one Error issue was discovered in Systemd in format_timespan()
function of time-util.c. An attacker could supply specific values for
time and accuracy that leads to buffer overrun in format_timespan(),
leading to a Denial of Service.
Add a patch to solve above CVE issue
Link: 9102c625a6
(From OE-Core rev: e2db40ca49b8ed217f14c7f861087837e8b3f389)
Signed-off-by: Ranjitsinh Rathod <ranjitsinh.rathod@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the path to bitbake.lock is in a deep directory, bitbake will hang. The
reason was that the max file length limiting code (to 255 chars) was including
the directory name and it should only act on the filename within the directory.
Fix it to just use the base filename.
[YOCTO #14766]
(Bitbake rev: e3db9c2e9eded3c5cb6040714a6054b44f6b3880)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 89d70e7b71eecfe06592202f326e566c579ba01d)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The fetcher mirror code can go crazy creating lock filenames which exceed the
filesystem limits. When this happens, the code will loop/hang.
Handle the filename too long exception correctly but also truncate lockfile
lengths to under 256 since the worst case situation is lockfile overlap
and lack of parallelism.
(Bitbake rev: 30d42ef030d03e11322b6b05ea7bbb64ab3d6f21)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 63baf3440b16e41ac6601de21ced94a94bdf1509)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need the system tar to be GNU tar, as we reply on --xattrs. Some
distributions may be using libarchive's tar binary, which is definitely
not as featureful, so check for this and abort early with a clear
message instead of later with mysterious errors.
(From OE-Core rev: 8f852648fe730615c99bcdaace8a4748ef4e96a5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 7dd2b1cd1bb10e67485dab8600c0787df6c2eee7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The trailing slash in ${B} caused -fdebug-prefix-map=${B}=... to not
match as intended, resulting in ${TMPDIR} ending up in files in
${PN}-dbg when externalsrc was in use, which in turn triggered buildpath
QA warnings.
(From OE-Core rev: fa89e048e223ae2e96d0f55979f93f29904b5229)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 9b5031ed5a0d102905fa75acc418246c23df6eef)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fix issue introduced in:
https://git.openembedded.org/openembedded-core/commit/?id=95fbac8dcad6c93f4c9737e9fe13e92ab6befa09
* it added check for s_dir + git-dir (typically '.git') isn't
the same as ${TOPDIR} + git-dir, but due to copy-paste issue
it was just comparing it with s_dir + git-dir again, resulting
in most external repos (where git-dir is '.git') to be processed
as regular directory (not taking advantage of git write-tree).
* normally this wouldn't be an issue, but for big repo with a lot of
files this added a lot of checksums in:
d.setVarFlag('do_compile', 'file-checksums', '${@srctree_hash_files(d)}')
and I mean *a lot, e.g. in chromium build it was 380227 paths
which still wouldn't that bad, but the checksum processing in
siggen.py isn't trivial and just looping through all these
checksums takes very long time (over 1000sec on fast NVME drive
with warm cache) and then
https://git.openembedded.org/bitbake/commit/?id=b4975d2ecf615ac4c240808fbc5a3f879a93846b
made the processing a bit more complicated and the loop in
get_taskhash() function took 6448sec and to make things worse
there was no output from bitbake during that time, so even with -DDD
it looks like this:
DEBUG: virtual/libgles2 resolved to: mesa (langdale/oe-core/meta/recipes-graphics/mesa/mesa_22.2.0.bb)
Bitbake still alive (no events for 600s). Active tasks:
Bitbake still alive (no events for 1200s). Active tasks:
Bitbake still alive (no events for 1800s). Active tasks:
Bitbake still alive (no events for 2400s). Active tasks:
Bitbake still alive (no events for 3000s). Active tasks:
Bitbake still alive (no events for 3600s). Active tasks:
Bitbake still alive (no events for 4200s). Active tasks:
Bitbake still alive (no events for 4800s). Active tasks:
Bitbake still alive (no events for 5400s). Active tasks:
Bitbake still alive (no events for 6000s). Active tasks:
DEBUG: Starting bitbake-worker
without -DDD it will get stuck for almost 2 hours in:
"Initialising tasks..."
before it finally writes sstate summary like:
"Sstate summary: Wanted 3102 Local 0 Mirrors 0 Missed 3102 Current 1483 (0% match, 32% complete)"
* fix the copy&paste typo to use git work-tree in most cases, but
be aware that this issue still exists for huge local source
trees not in git
[YOCTO #14942]
(From OE-Core rev: 1f0e4de8d92edd7438d462c779d917ac0ccd5499)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 9102e5a94b8146cb1da27afbe41d3db999a914ff)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
