It could be argued that we could keep the fragments and virtualization
.inc file for old versions, as they won't trigger and immediate issue
for configurations that are using the older supported kernel versions.
BUT, we could extend that comment to any / all versions ever supported
by OEcore.
Since 6.6 isn't actively being tested in master, let's drop all
the references and only have 6.12 active. If someone does need the
older kernel support, then the support could be restored.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Bumping the SRCREV to pick up the following commits:
8650ed99 docker: enable ipvlan and build BRIDGE_VLAN_FILTERING into kernel
38e7c7aa docker: inherit base container and BPF configs
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
When using externalsrc, the system will disable a number of tasks such as
do_validate_branches, do_unpack and do_patch. The do_kernel_metadata task
is configured to run after do_validate_branches do_unpack and before
do_patch. Since all of these have been removed, the task will never
run.
The do_kernel_metadata task is responsible for populating the
recipe-sysroot-native/kcfg directory via it's own dependency to
yocto-cfg-fragments-native:do_populate_sysroot.
Without do_kernel_metadata running, do_kernel_configme will fail to run
with errors like:
ERROR: linux-xlnx-6.6.40+git-r0 do_kernel_configme: Feature '../recipe-sysroot-native/kcfg/cfg/virtio.scc' not found, this will cause configuration failures.
ERROR: linux-xlnx-6.6.40+git-r0 do_kernel_configme: Check the SRC_URI for meta-data repositories or directories that may be missing
ERROR: linux-xlnx-6.6.40+git-r0 do_kernel_configme: Set KERNEL_DANGLING_FEATURES_WARN_ONLY to ignore this issue
Fix this issue by detecting if we're running with externalsrc, and then
adding the task do_kernel_metadata (from the current recipe) as a
dependency of do_kernel_configme.
To reproduce th original issue:
$ . ./oe-initbuild-env
$ bitbake linux-yocto -c patch
$ cp -r tmp/work-shared/<machine>/kernel-source linux-yocto
edit the conf/local.conf adding:
DISTRO_FEATURES:append = " virtualization"
INHERIT += "externalsrc"
EXTERNALSRC:pn-linux-yocto = "${TOPDIR}/linux-yocto"
$ rm -rf tmp
$ bitbake linux-yocto -c menuconfig
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
There's no sense adding a fragment dependency to kernels
that don't support merging. This commit restores the check
we previously had for an inherit of kernel-yocto before
adding the configuration fragmment dependency.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The routine calculating the -native depdenency for configuration
fragments had issues with variations in kernel PV definitions.
To avoid making the routine even more complex, this commit switches
to using the same variables that include the correct virtualization
include file. This way, if bitbake has located and included the
file that adds the -native dependency, we know that the variables
will find the correct recipe.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* it was introduced in:
https://git.yoctoproject.org/meta-virtualization/commit/?id=a940a0e873f9163d4585555b3f3d38e99400d237
but it doesn't work well when PREFERRED_VERSION is set to e.g. "6.6.%",
you remove the '%' but not the trailing dot, causing:
ERROR: Nothing PROVIDES 'yocto-cfg-fragments-6.6.-native'. Close matches:
yocto-cfg-fragments-6.10-native
yocto-cfg-fragments-6.6
yocto-cfg-fragments-6.6-native
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
When more than one kernel is supported in oe-core, we may have
situations where the options from an older (or newer) kernel
are not appropriate for the other version (i.e. options have
been added, removed or renamed).
To support this we check the preferred version of the kernel
and depend on a specific yocto-cfg recipe.
This is similar to how the virtualization .inc files are
chosen.
If this technique proves to be correct, we can factor the
common routines into a .inc and just set SRCREVs in the
individual .bb files.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
kernel version 6.10 will be the next reference kernel, so we
add the .inc file to enable the configuration
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Now that UNPACKDIR is used to unpack sources we have an
extra level of indirection to locate our cloned fragments.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
distro optional features need to ensure that they are space
separated or we'll have configuration failures.
Additionally, always add a local configuration fragment for
easy debug and enablement of options.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
We've had duplicate fragments in the kernel-cache and the meta-virt
layer for quite some time (i.e. docker).
To more easily keep these in sync, promote the sharing of fragments
and to allow them to be used even when meta-virt isn't part of
a build, we change our feature additions to use the yocto-kernel-cfg
clone of the kernel-cache instead of the ones in our layer.
It remains to be seen if any other kernel recipes will run into
issues with this movement of the fragments, so we mark this as a
WIP/RFC.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Currently Xen expected a tun module to be packaged. We need
a better way to resolve dependencies such as this (perhaps
by the kernel providing the package requested when functionality
is built in).
But for now, without a compelling need for criu to have tun
built in, we tweak this config to match and keep the xen builds
happy and with no conditional package requirements.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
criu needs to turn on sock diag features in kernel to do the system dump[1].
Ref:
[1] https://criu.org/Linux_kernel
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Adding support for the 6.6 kernel series as testing has been
completed against linux-yocto v6.6/*
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Allow the kernel include file to be skipped, even if a
kernel is capable of merging and using the fragments in
the layer and kernel-cache.
Setting SKIP_META_VIRT_KERNEL_INCLUDE="t" in a kernel
bbappend, or in a configuration file will inhibit the
generated / detected include file.
BUT
If that opt-out is done, we warn, as the user has
explicitly disabled safeguards that help ensure that
subtle runtime issues aren't introduced.
BUT
If someone really knows what they are doing, they
don't want the warning to be present in each build.
So setting META_VIRT_KERNEL_CHECK_WARNING_INHIBIT="t"
will inhibit the message.
At that point, you have jumped through all the hoops
and you are free to ensure your kernel configuration
is correct using other means.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The 6.5 kernel has now been tested against core and meta-virtualization
so we add the .inc file to show that status.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
5.15 hasn't been in master for quite some time, so we drop
our version matching .inc
Support for 5.15 can be found on release branches.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The more generic linux-%.bbappend will match on linux-yocto-dev.
If we have the version specific .inc files in the layer, then we
will have support for linux-yocto-dev. Since we already track
the linux-yocto-tested versions, it isn't hard to track the -dev
kernel version.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The major stacks have been tested against 5.19, so we add the
tracking .inc to indicate support.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
K3s (and Kubernetes) supports load balancing via IPVS, and by default reports
errors when IPVS kernel modules cannot be loaded.
This patch adds the missing reported kernel modules to the k3s recipe:
* ip-vs
* ip-vs-rr
* ip-vs-wrr
* ip-vs-sh
The modules are configured by including the ip_vs kernel feature.
Signed-off-by: Richard Neill <richard.neill@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
The removal of the .inc was pushed prematurely. We'll remove it
again, once 5.14 is removed from core and 5.15 is the default.
This reverts commit 79e0e4598c.
5.14 has been removed from core, and is EOL upstream. We drop our 5.15
.inc file to match that status.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Adds the following kernel modules for k3s:
* xt-physdev
* xt-nflog
* xt-limit
* nfnetlink-log
Without them, the k3s network-policy-controller reports failures in the log
related to iptables-restore.
Signed-off-by: Richard Neill <richard.neill@arm.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
* fixes:
KERNEL_FEATURES:append += is not a recommended operator combination, please replace it.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
To help enforce/guide consistent configuration and to avoid duplicating
configuration fragments into the meta-virt layer, we leverage a native
provider of the yocto-kernel-cache fragment repository.
To allow support for kernels that support fragments, but don't have the
yocto-kernel-cache in the kernel's SRC_URI, we create two conditional
parts of the virtualization configuration.
If virtualization is enabled in the distro features, the kernel
version matches one of our supported ones, and the kernel inherits
kernel-yocto, we add a depedency on the yocto-cfg-fragments-native
recipe.
That recipe will install the fragment collection to the kernel recipe's
native sysroot.
We can then check for the kernel-cache on the SRC_URI. If it is present,
we use the feature at the standard location. If it is not present, we
add the fragment from the native sysroot.
While we could always use the native sysroot variant, we want to allow
a kernel with a kernel-cache to be the first choice, and provide their
own fragments.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
To allow the use of the yocto configuration fragments in scenarios where
a kernel inherits kernel-yocto or has a custom fragment implementation, but
doesn't directly include the yocto-kernel-cache in the kernel SRC_URI,
we introduce a native provider of the fragments.
This fragment provider is independent of a kernel tree and when added
as a dependency to a recipe, the fragments will be placed in:
recipe-sysroot-native/kcfg/
These can then be referenced on the SRC_URI or in KERNEL_FEEATURES by
using '../recipe-sysroot-native/kcfg' as the relative path to the
.scc or .cfg file. In the future, this won't be required as kernel-yocto
will always check the native sysroot for fragments, and fragments will
always be referenced by relative path from the base of the kernel-cache.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
5.13 hs been removed from core, so we drop our associated
configuration include. 5.14 is now the default.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
OEcore/bitbake are moving to use the clearer ":" as an overrides
separator.
This is pass one of updating the meta-virt recipes to use that
syntax.
This has only been minimally build/runtime tested, more changes
will be required for missed overrides, or incorrect conversions
Note: A recent bitbake is required:
commit 75fad23fc06c008a03414a1fc288a8614c6af9ca
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Sun Jul 18 12:59:15 2021 +0100
bitbake: data_smart/parse: Allow ':' characters in variable/function names
It is becomming increasingly clear we need to find a way to show what
is/is not an override in our syntax. We need to do this in a way which
is clear to users, readable and in a way we can transition to.
The most effective way I've found to this is to use the ":" charater
to directly replace "_" where an override is being specified. This
includes "append", "prepend" and "remove" which are effectively special
override directives.
This patch simply adds the character to the parser so bitbake accepts
the value but maps it back to "_" internally so there is no behaviour
change.
This change is simple enough it could potentially be backported to older
version of bitbake meaning layers using the new syntax/markup could
work with older releases. Even if other no other changes are accepted
at this time and we don't backport, it does set us on a path where at
some point in future we could
require a more explict syntax.
I've tested this patch by converting oe-core/meta-yocto to the new
syntax for overrides (9000+ changes) and then seeing that builds
continue to work with this patch.
(Bitbake rev: 0dbbb4547cb2570d2ce607e9a53459df3c0ac284)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Add kernel config fragment according to the requirement from the file
types_unix.go in source codes of kubernetes.
Signed-off-by: Zqiang <qiang.zhang@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
We already have docker and some other fragments that are relevant to
k3s/k8s, but the addition of ipset as a depends for k3s highlights
that we should have a reference configuration that sets all the options
for proper opration and runtime dependencies.
When k8s or k3s are distro features, we'll apply the new fragment to
any kernel that supports fragments (and matches the supported
versions).
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
