The osbuilder needs to set up libseccomp library to build the kata-agent
because the kata-agent supports seccomp currently.
The library is built from the sources to create a static library for musl libc.
In addition, environment variables for the libseccomp crate are set to
link the library statically.
Fixes: #1476
Signed-off-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
The oci_to_grpc function just handles part of oci fields,
and others are not copied from oci spec to grpc spec,
such as process.env, process.capabilities, mounts and so on.
Try to implement more handlings to convert thoses fields.
Fixes#2686
Signed-off-by: Lei Li <cdlleili@cn.ibm.com>
- Install OpenSSL for key generation in kernel build
- Do not install libpmem
- Do not exclude `*/share/*/*.img` files in QEMU tarball since among
them are boot loader files critical for IPLing.
Fixes: #2895
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
This is to bump the OOT QAT 1.7 driver version to the
latest version. I dida test on my QAT enabled system and
everything functioned as expected.
Fixes: #2877
Signed-off-by: Eric Adams <eric.adams@intel.com>
This commit will add containerd to versions.yaml.
Please at now there are both containerd and cri-containerd
in the versions.yaml.
After updating of kata-containers/tests repo, the cri-containerd
should be removed.
Fixes: #2791
Signed-off-by: bin <bin@hyper.sh>
When building with dracut method the build_rootfs_distro() is not called, in turn
detect_rust_version() isn't either, so the install_rust.sh script is gave a null
rust version. This changed the script to call detect_rust_version() right before
install_rust.sh.
Related to commit: f34f67d610Fixes#2862
Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
and update the script in `ci/` accordingly.
When only parts of the Kata Containers repositories are checked out
(e.g. when building with Snap) and no Rust version is provided in
calling `install_rust.sh`, the scripts will attempt to clone the
appropriate repos to read the version, which will fail because the
directories already exist. Since we have read the version already, we
can just specify it.
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
The agent build inside a Docker or Podman container has been re-enabled,
but we have since introduced the `$CI` environment variable. Pass it to
avoid checking out the tests repo to main when there is a dependency.
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
or Podman. This is a partial revert of
76c18aa345. The rationale behind that
commit was the fact that the agent could not be built on Alpine, and
then this capability was removed altogether. The issue in Alpine has
since been resolved (see
https://github.com/kata-containers/osbuilder/issues/386). At the same
time, this ensures being able to run a glibc agent on hosts with distros
more recent than the osbuilder distro used (i.e. as of now, when you
build the agent on the host, and its glibc is newer than the one used in
the guest, the agent may encounter unresolved symbols).
Fixes#2398
Signed-off-by: Jakob Naucke <jakob.naucke@ibm.com>
.dockerignore file is similar to .gitignore and serves the purpose to
simply ignore paths in the build context.
For now, let me just use it to fix the following problem:
```
docker build --build-arg KATA_ARTIFACTS=kata-static.tar.xz .
error checking context: 'no permission to read from
'(...)/local-build/build/firecracker/builddir/firecracker/(...)/crc64-1.0.0/.gitignore''.
```
Fixes: #2845
Signed-off-by: Fabiano Fidêncio <fabiano@fidencio.org>
The guest kernel configuration suggested for Kata, and which is used by the
CI didn't include CONFIG_PCI_MMCONFIG. That's kind of weird, MMCONFIG is
the modern normal way of handling configuration cycles.
In addition, due to a complex set of interactions through the ACPI code,
disabling MMCONFIG means that SHPC hotplug doesn't work: the driver is
included in the guest kernel, but will fail to probe on PCI to PCI bridges,
meaning it won't actually be activated.
Enable MMCONFIG so that we suggest and testa more typical guest kernel
configuration.
fixes#2288
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We explicitely set the Postion Independant Executlable (PIE) options
in the extra CFLAGS and LDFLAGS that are passed to the QEMU configure
script for all archs. This means that these options are used pretty
much everywhere, including when building the sample plugins under the
test directory. These cannot be linked with -pie and break the build,
as experienced recently on ARM (see PR #2732).
This only broke on ARM because other archs are configured with
--disable-tcg : this disables plugins which are built by default
otherwise.
The --enable-pie option is all that is needed. The QEMU build system
knows which binaries should be created as PIE, e.g. the important
bits like QEMU and virtiofsd, and which ones should not, e.g. the
sample plugins that aren't used in production.
Rely on --enable-pie only, for all archs. This allows to drop the
workaround that was put in place in PR #2732.
Fixes: #2757
Signed-off-by: Greg Kurz <groug@kaod.org>
The centos ppc64le gpg key at mirror.centos.org doesn't exist (link rot?).
Replacing it with url from CentOS/sig-core-AltArch on github.
Fixes: #2676
Signed-off-by: Aaron Simmons <paleozogt@gmail.com>
Optional build types are common for early adoption.
Lets add a flag to build and optional config.
e.g.
kernel-build.sh -b experimental
In the future instead of add more flags just add a new build type.
Signed-off-by: Carlos Venegas <jose.carlos.venegas.munoz@intel.com>
After 5.11-rc4, memory hotplug alignment size is reduced to 128M for 4K
page.
It works better for memory hotplug and nvdimm plug in kata on arm.
without this patch, memory hotplug will fail for the current memory
hotplug alignment is 1G but the nvdimm size align with 128M in kata.
After port it here, we can avoid a fix in qemu side.
Note: if you change the page size to other size than 4K, memory hotplug
will has no effect.
Fixes: #2707
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
For qemu 6.1.0 build on arm64, compile error occurs when "-pie" is added
to ldflag.
tests/plugins/empty.c won't be linked as a sysmbol is missing.
I consider there maybe a bug.
Before figure it out, we should disable plugins for qemu 6.1.0 on arm64.
Fixes: #2707
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Since the qemu upgrade to v6.1.0, the build fails
with a linking issue. Adding --disable-tcg to fix
it.
Fixes: #2710
Signed-off-by: Amulya Meka <amulmek1@in.ibm.com>
A related dir is needed when apply qemu patch using script. As qemu 5.1
is used for arm, a dir of "v5.1.0" is needed under tag_patches.
Fixes: #2696
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Let's make it as clear as possible for the user that if they go for a
tagged version of kata-deploy, eg, 2.2.1, they'll have the kata runtime
2.2.1 deployed on their cluster.
Suggested-by: Eric Adams <eric.adams@intel.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's add more instructions in the README in order to make clear to the
reader what they can do to check whether kata-deploy is ready, or
whether they have to wait till proceeding with the next instruction.
Suggested-by: Eric Adams <eric.adams@intel.com>
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
There's only one QEMU runtime class deployed as part of kata-deploy, and
that includes virtiofs support (which is the default for quite some time
already). Knowing this, let's just remove the `qemu-virtiofs` runtime
class definition.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's teach our `update-repository-version.sh` script to properly update
the kata-deploy tags on both kata-deploy and kata-cleanup yaml files.
The 3 scenarios that we're dealing with, based on which branch we're
targetting, are:
```
1) [main] ------> [main] NO-OP
"alpha0" "alpha1"
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "latest" | "latest" |
-----------------+----------------+----------------+
kata-deploy-base | "stable | "stable" |
-----------------+----------------+----------------+
2) [main] ------> [stable] Update kata-deploy and
"alpha2" "rc0" get rid of kata-deploy-base
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "latest" | "rc0" |
-----------------+----------------+----------------+
kata-deploy-base | "stable" | REMOVED |
-----------------+----------------+----------------+
3) [stable] ------> [stable] Update kata-deploy
"x.y.z" "x.y.(z+1)"
+----------------+----------------+
| from | to |
-----------------+----------------+----------------+
kata-deploy | "x.y.z" | "x.y.(z+1)" |
-----------------+----------------+----------------+
kata-deploy-base | NON-EXISTENT | NON-EXISTENT |
-----------------+----------------+----------------+
```
And we can easily cover those 3 cases only with the information about
the "${target_branch}" and the "${new_version}", where:
* case 1) if "${target_branch}" is "main" *and* "${new_version}"
contains "alpha", do nothing
* case 2) if "${target_branch}" is "main" *and* "${new_version}"
contains "rc":
* change the kata-deploy & kata-cleanup tags from "latest" to
"${new_version}".
* delete the kata-deploy-stable & kata-cleanup-stable files.
* case 3) if the "${target_branch}" contains "stable":
* change the kata-deploy & kata-cleanup tags from "${current_version}"
to "${new_version}".
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Similar to the instructions we have for the "latest" images, let's also
add instructions about the "stable" images.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Let's just point to our repo URLs rather than assume users using
kata-deploy will have our repo cloned.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This is **not** the nicest patch of my career, and I know it adds code
duplication. However, I've decided to take this approach in order to
have easier / better instructions for users who're consuming
kata-deploy.
Having both stable & latest yaml on `main` will let us point to just one
place, without having to update the instructions.
I know, would be better to have those generated from a .in file,
wouldn't it? For sure, but then we'd lose the ability to just point to
those files from kata-deploy pages (either on dockerhub or quay.io).
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Instead of point to a specific release number, let's point to the
`latest` tag on the main branch.
There's still some work needed in order to point to the `stable` tag on
the stable-x.y branches, as this is something that should be done
automagically as part of the release process.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
This brings it back into line with the normal qemu version. We refer to
v6.1.0 by full SHA in versions.yaml, rather than the tag, so that
apply_patches.sh sees it as different and applies the virtiofs DAX patches
which is what the experimental version is actually about having.
The virtiofs DAX patches themselves are updated to the version from
https://gitlab.com/virtio-fs/qemu, virtio-fs-dev branch as of commit
3620cb0a.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We need qemu-6.1 for ACPI PCI hotplug support for the q35 machine. At the
moment qemu will use SHPC hotplug under the PCIe to PCI bridge on q35.
SHPC is too slow to use for our purposes (it requires a 5s delay).
Update the qemu version to v6.1.0. This leaves the experimental version
*older* than the normal version, but we'll fix that up later.
We also need to tweak the snapcraft.yaml, since the location for configs
has changed in the new qemu version.
fixes#1691
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If the script doesn't find a patches directory it expects, it gives an
error saying to create a dummy 'no_patches' file if you really don't want
any patches applied for that version.
But actual practice in the tree is to call the dummy file 'no_patches.txt'
rather than simply 'no_patches'. Correct the message to match existing
practice.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If a binary tarball for a single component is done,
the logs will be shown in stdout.
e.g.
make kernel-tarball
To build all a the same time still store logs in files.
make kata-tarball
Signed-off-by: Carlos Venegas <jose.carlos.venegas.munoz@intel.com>
Now that local-build kata-deploy makefile is inlucded in toplevel
makefile, lets use the suffix `-tarball` to avoid name collitions
and identify the tarball releted targets.
Signed-off-by: Carlos Venegas <jose.carlos.venegas.munoz@intel.com>
zsh doesn't support "==" as equal comparison operator, so
replace "==" with "=" to make the script more portable
Fixes: #2584
Signed-off-by: Binbin Zhang <binbin36520@gmail.com>
