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>
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>
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>
* 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>
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>
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>
Add kernel config fragment for CONFIG_CGROUP_HUGETLB
This is a recommended config for Kubernetes and k8s
will throw a warning if it is not present.
Signed-off-by: Tim Orling <ticotimo@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Instead of setting virtio kernel configs in LXC fragment, just reuse
cfg/virtio.scc from yocto-kernel-cache.
Signed-off-by: Chin Huat Ang <chin.huat.ang@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
In the v4.18 kernel, there is a problem with the locking and init sequence of
the kernel modules. This would cause nf_conntrack_ipv6 failed to be loaded.
In kernel v4.19, nf_conntrack_ipv6 has been merged to nf_conntrack and the
problematic code has gone. This patch just works around by forcedly loading
nf_conntrack_ipv6.
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
systemd-modules-load.service bindly load whatever in modules-load.d/*.conf,
in this case, kvm_intel and kvm_amd. One of them must fail on a specific
board and causes the following failure.
This patches remove them from KERNEL_MODULE_AUTOLOAD and leaves them to udev.
systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Failed to start Load Kernel Modules.
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Make these bbappend files to take effect only when DISTRO_FEATURES
contain 'virtualization'. Otherwise, we would meet failure failure
at system booting up qemux86. Related logs are as below.
systemd-modules-load[113]: Failed to insert 'kvm_amd': Operation not supported
systemd-modules-load[113]: Failed to insert 'kvm_intel': Operation not supported
Also, make kvm related settings depend on the 'kvm' distro feature.
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
